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This  thesis  addresses  the  initial  development  stages  of 
an  automated  Management  Information  System  (KIS)  for  use  by 
the  purchasing  activity  at  tae  Naval  Postgraduate  School. 
It  initially  examines  the  policies,  practices,  procedures 
and  processing  techniques  employed  in  the  ton-automated 
environment,  and  identifies  key  elements  of  interest  which 
can  be  captured  through  automated  techniques  to  improve  the 
level  of  management  information  available.  A  system  to 
capture,  edit,  input  and  store  this  information  is 
discussed,  and  an  extensive  analysis  of  the  necessary  output 
reports  is  offered.  The  thesis  concludes  by  sizing  the  phys¬ 
ical  requirements  of  the  system  and  making  specific 
recommendations  regarding  generic  hardware  requirements. 
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I.  INTRODUCTION 


A.  GENERAL 

The  process  of  change  or  transformation  is  difficult  to 
initiate  within  any  established  organization.  In  1513 
Machiavelli  observed: 

’’There  is  nothing  more  difficult  to  plan,  more  doubtful 
of  success,  nor  more  dangerous  wO  manage  than  *he 
oreation^of  a  new  system.  For  the  initiator  has  the 
enmity  of  all  who  would  profit  by  the  preservation  of 
the  old  system  and  mereLy  lukewarm  defenders  in  these 
who  would  gain  by  the  new  one." 

These  words  are  as  accurate  today  as  in  1513  and  are 
most  appropriate  to  any  discussion  regarding  the  development 
of  a  management  information  systen  (rtlS) .  Such  a  system 
must  consider  what  is  apparently  an  endless  succession  of 
physical  ar.d  social  patterns  of  interaction,  ranging  from 
document  preparation  and  flow  to  the  socio-political  aspects 
of  each  job  position  within  the  organization.  An  approach 
of  this  nature  may  seem  overly  broad  to  most,  but  in  actu¬ 
ality,  is  the  only  reasonable  approach  to  take  if  one  wishes 
to  truely  integrate  an  MI3  into  the  daily  routine.  Systems 
which  have  failed  to  consider  this  broad  spectrum  have  typi¬ 
cally  ended  in  disuse  because: 

1.  The  end  product  was  unsuitable  due  to  inadequate 
research  and  development. 

2.  The  end  product  was  efficient  but  not  effective  as 
viewed  by  the  users. 

3.  The  'shock'  of  change  and  the  manner  in  which  the 
conversion  was  accomplished  resulted  in  rebellion  by 
users--- per  haps  to  the  point  of  sabotage  to  the  system. 
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B.  PURPOSE 


This  paper  will  document  the  development  of  a  Management 
Information  System  (MIS)  for  use  oy  rhe  purchasing  activity 
at  the  Naval  Postgraduate  School  by  addressing  the  policies, 
practices,  procedures  and  processing  techniques  currently  in 
use,  and  by  offering  recommended  changes  to  the  existing 
system  which  will  enhance  both  the  efficiency  and  effective¬ 
ness  of  the  organization. 

C.  APPROACH 

The  quantum  improvements  in  office  automation  and  infor¬ 
mation  systems  in  general  during  the  last  decade  have  been 
unprecedented.  These  improvements  have  prompted  ongoing 
reviews  of  intra-office  efficiency  and  effectiveness  and 
stimulated  the  collective  imagination  of  every  office 
manager.  In  the  private  sector,  the  guest  for  improvements 
in  management  information  has  been  spurred  on  by  the  ever 
present  profit  motive  and  desire  to  accomplish  more  witn 
less  input.  within  the  Department  of  Defense,  the  dual 
forces  of  increasing  budgetary  constraint  and  decreasing 
personnel  availability  have  precipitated  similar  reviews. 
Automation  of  the  purchasing  activity  at  the  Naval 
Postgraduate  School  is  being  pursued  as  a  means  of  enhancing 
management’s  control  and  understanding  of  the  work 
environment — thus  improving  the  effectiveness  and  efficiency 
of  individual  workers. 

The  author  has  approached  this  project  having  been 
advised  that  automation  of  the  purchasing  activity  is  a 
primary  goal  and  that  some  form  of  "computerization"  will 
ultimately  be  applied.  \t  this  time,  however,  there  is  no 
indication  as  to  the  type  of  system  desired  or  the  type 
which  is  best  suited  to  the  needs  of  the  activity.  Many 
options  are  a  vailable-- r  ar.gi  r.g  from  a  time  sharing 


arrangement  on  an  existant  Navy-owned  mainframe  facility  to 
a  sore  dedicated  system  composed  of  a  small  mini  or  micro 
computer  and  associated  pe  riph  ec  als.  It  is  fait  that  ths 
nature  of  the  existing  activity,  aid  that  of  similar  small 
purchasing  activities  Navy -wile,  is  most  conducive  to  the 
application  of  computerizes  technology. 

D.  RESEARCH  QUESTION 

The  research  questioi  for  this  study  is:  "How  can 

quantum  improvements  in  conputar  technology  best  ba  applied 
to  the  Naval  Postgraduate  School  purchasing  activity  to 
enhance  management  control  and  decision  malting?"  The 
following  ancillary  issues  will  be  addressed: 

1.  What  management  information  is  currently  being 
utilized? 

2.  What  new  forms  of  information  could  be  economically 
developed  to  assist  in  managing  the  purchasing 
activity? 

3.  Could  new  information  forms  be  developed  for  dissemina¬ 
tion  at  the  lowest  levels  of  the  oroaaization  to 
improve  buyer  awareness  of  individual  performance? 

'4.  Given  a  requirement  to  constrict  a  computerized  data 
base,  what  data  elements  are  appropriate  to  capture  and 
how  could  they  be  used? 

5.  What  hardware  types  and  what  capacities  are  required  to 
support  an  MIS  for  a  small  purchasing  activity? 

E.  SCOPE  AND  LIMITATIONS 

This  analysis  is  being  conducted  with  some  degree  of 
predisposition  in  that  tie  decision  to  apply  some  form  of 
automation  to  the  activities  of  tie  purchasing  branch  is  a 
fait  accompli,  and  that  senior  management  personnel  within 
the  Supply  Department  have  elected  to  begin  this  process  by 


initially  implementing  an  IIS.  No  attempt  is  being  and**-  to 
develop  a  completely  automated  transaction  processing 
system.  However,  collection  of  data  on  every  transaction  is 
absolutely  necessary  to  tne  developnent  of  accurate  manage¬ 
ment  information,  and  it  is  reasonable  to  assume  that 
follow-on  development  should  be  able  to  use  the  existing 
data  base  configuration  to  further  develop  a  fully  automated 
transaction  processing  system.  The  approach  throughout  this 
study  is  one  of  complete  autonomy  of  system  design.  Impact 
upon  the  operations  of  other  branches  and/or  divisions 
within  the  Supply  Department  is  not  desired. 

F.  ASSUMPTIONS 

The  following  assumptions  have  been  made  regarding  the 
design  of  this  system: 

1.  Cost  and  reliability  of  the  system  are  primary 
constraints  to  be  considered  in  the  development 
process.  Ideally,  this  systsn  should  be  highly  reli¬ 
able  yet  cost  less  tian  $10,333.00  i-o  facilitate  its 
procurement . 

2.  The  system  should  be  a  separate  information  system  and 
should  not  directly  affect  production  wit  a  in  the  work 
unit — except  in  the  sense  that  it  improvements  effi¬ 
ciency  through  better  management  control. 

G.  ORGANIZATION  OF  STUDY 

This  study  has  been  Logically  organized  to  present  the 
reader  with  an  initial  ai a  lysis  of  tne  system  as  it  exists 
in  its  purely  manual  form.  It  then  transitions  to  a  proposed 
system  which  will  improve  management  control  of  the  work 
unit  by  supporting  data  element  capture  and  report  genera¬ 
tion  through  automated  means.  Tne  final  chapter  makes 
specific  recommendations  ragarding  hardware  acquisition  for 
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II.  ANALYSIS  OF  C3RRENT  PROCEDURE 


A.  ORGANIZATION 

The  Purchasing  Branca  is  responsible  for  effecting  the 
procurement  of  non-standard  material  or  services  for  the 
Naval  Postgraduate  School  and  approximately  9  other  commands 
within  the  geographical  area.  Typically,  this  entails 
processing  1,000  procurement  transactions  each  month, 
ranging  from  no  cost  to  hundreds  of  thousands  cf  dollars. 
This  workload  is  handled  by  5  buyers,  each  of  which  has 
varying  degrees  of  knowledge  regarding  the  procurement 
process,  and  some  of  which  specialize  in  specific  types  cf 
transactions.  This  organization  is  functionally  effective 
but  lacks  the  management  controls  necessary  to  truely  opti¬ 
mize  per  f  or  ma  nc  e  . 

Before  proposing  changes  to  the  existing  system,  and 
the  development  of  a  new  information  system  that  will  better 
support  the  needs  of  management,  it  seems  appropriate  to 
describe  the  present  organizatipnal  structure.  Figure  2.1 
depicts  the  overall  organization  of  tie  Supply  Department. 

Note  that  the  purchasing  function,  which  is  the  focus  of 
this  study,  is  assigned  to  the  branch  level  of  hierarchy 
under  the  cognizance  of  the  Control  Division.  The  purpose 
of  the  Control  Division  is  to  provide  for  the  contracting  of 
suoplies  and  services,  the  requisitioning  of  materials,  and 
the  processing  of  invoices  for  payment.  To  accomplish  these 
responsibilities  the  Control  Division  has  been  subdivided 
into  the  Issue/Receipt  Control  and  Purchasing  Branches. 
Figure  2.2  depicts  the  functional  resonsibilities  of  these 
two  branches. 
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Pigure  2.1  Supply  Dspartaent  Organization  Chart. 


FUNCTION 

Technical  edit  and  review 
Standard  Stock  Acquisition 
Non-Std.  Stock  Acquisition 
Status  Maintenance 
Follow-up 

Receipt/Invoice  process i na 


RESPONSIBLE  BRANCH 
I/R  Control  Branch 
I/R  Control  Branch 
Purchasing  Branch 
I/S  Control  Eranch 
I/R  Control  Branch 
I/S  Control  Branch 


Figure  2.2  Functional  Responsibilities  by  Branch. 


B.  REVIEW  OF  FU  HCTIOHAL  RESPONSIBILITIES 

Of  the  functions  listed  in  Figure  2.2  only  the  acquisi¬ 
tion  of  non-standard  materials  is  coasidered  to  be  under  the 
cognizance  of  the  Purchasing  Branch.  However,  the  technical 
edit  and  review  function  directly  inpacts  upon  the  workload 
of  the  Purchasing  Branch  and  for  this  reason  will  be 
included  in  the  discussion.  For  purposes  of  this  study  the 
treatment  of  these  two  functional  responsibilities  will  be 
limited  to  the  discussion  of  primary  functions,  decisions, 
and  information  flows  associated  with  the  recurrim 


processes. 

1.  Technical  Edit  and  Review 

The  primary  purpose  of  this  function 
that  requisitions  submitted  to  the  Supply  Dep 
the  proper  format  and  that  required  informat 
In  addition,  each  requisition  is  reviewed  to 


the  material  falls  into  a  material  category  that  requires 
spacial  processing. 

There  are  two  general  types  of  requisitior.s--t.hose 
which  are  for  standard  stock  material  and  those  which  are 
not.  Each  type  follows  a  particular  processing  path  througn 
the  control  division,  and  must  therefore  be  discussed  sepa¬ 
rately.  Prior  tc  being  received  b:  the  control  division  ail 
requisitions  are  reviewed  by  the  Controller  Department  for 
financial  obligation  purposes  (Job  order  numbers  are  matched 
against  serial  numbers  to  insure  oil/  authorized  obligations 
are  permitted  further  processing). 

All  requisitions  are  submitted  on  a  DD  Form  1343,  or 
in  a  small  minority  of  cases  on  a  DD  Form  1149.  Figure  2.3 
is  an  example  of  a  completed  DD  Form  1348.  When  received  by 
the  Control  Division,  these  documents  are  time  stamped  and 
sorted  by  standard  and  non-standard  stock.  It  is  the  latter 
group  which  is  of  interest  to  the  Purchasing  Branch  since 
they  will  ultimately  become  new  inputs  to  tae  workload. 
Non-standard  requisitions  are  reviewed  to  determine  whether 
they  fall  into  one  of  the  following  categories  waioh  require 
special  processing  and/or  approval  authority: 

a.  Photographic  Equipment  of  Supplies 

b.  Reproduction  Equipment  or  Supplies 

c.  Filing  Equipment 

i.  Typewriters 

e.  Defense  Industrial  Plant  Equipment 

f.  Plant  Account  Material 

g.  Labor  Saving  Devices 

h.  Mandatory  Turn-in  Repairables  (MTS) 

Requisitions  are  also  reviewed  to  determine  if  the 
material  requested  is  carried  by  the  Ready  Supply  Store 
(RSS)  .  This  is  accomplished  by  searching  the  S33  inventory 
catalog.  If  the  material  is  carried,  the  DD  Form  1348  is 
returned  to  the  customer  lepartmeat  for  subsequent  submis¬ 
sion  to  the  RSS. 
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For  items  with  part  numbers  provided,  a  review  of 
the  Master  Cross  Reference  List  (MRCL )  is  performed.  If  a 
match  is  made,  the  stock  number  is  verified  against  the  Navy 
Management  Data  List  (NMDLl  to  determine  its  validity.  If 
it  is  a  good  stock  number  the  request  is  returned  to  the 
customer  department  for  preparation  of  a  standard  stock 
requisition.  If  a  cross  reference  is  not  made  or  if  a  stock 
number  proves  erroneous  based  upon  tie  NMDL  review,  a  final 
attempt  to  cross  reference  the  requested  item  to  a  national 
stock  number  may  be  mads  utilizing  the  following 
publications: 

a.  Afloat  Shopping  Guide 

b.  Federal  Supply  Schedules 


c.  General  Services  Administration  (3SA)  Catalogs 


It  is  important  to  note  that  the  degree  of  effort  expended 
upon  cross  referencing  a  given  procurement  request  is 
directly  dependent  upon  the  workload  and  the  level  of  expe¬ 
rience  of  the  personnel  assigned  to  the  task.  Not  all  items 
are  reviewed;  only  those  which  the  reviewer  feels  are  prime 
candidates  for  cross  referencing  based  upon  intuition  and 
experience  will  be  rigorously  reviews  1.  Upon  completion  of 
all  checks  and  reviews,  non-standard  stock  requisitions  are 
forwarded  to  the  Purchasing  Branch. 


2.  £H£ch as i ng  Branch  Review 

The  Purchasing  Branch  of 
responsible  for  the  acquisition 
material  required  to  support  the 
Postgraduate  School.  The  term 
material  which  is  not  routinely 
warehouses  and  has  therefore  not 


the  Supply  Department  is 
of  all  ’non-standard’ 
operation  of  the  Naval 
’non-standard'  refers  to 
stockpiled  in  government 
been  assigned  a  national 


stock  number  for  purposes  of  ordering  from  selected  stock 
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The  tasking  of  this  organization  is  like  that  of  any 
procurement  organization  within  the  Defense  Department 
however,  it  is  unique  in  the  sense  that  the  ratio  of  'non- 
standard1  to  'standard*  stook  aoquisitions  is  heavily 
inflated  in  favor  of  'non-standard*  material.  In  most  oper¬ 
ations  the  typical  mix  might  be  2D  %  'non-standard'  and  80 % 
•standard'.  This  is  completely  atypioal  of  the  operation  at 
the  Naval  Postgraduate  School  where  the  above  mix  is 
inverted  to  80$  'non-standard'  and  2D%  'standard'.  This 
disparity  is  attributed  to  the  unigie  nature  of  activities 
associated  with  a  university  environment  wherein  the 
majority  of  material  acquisitions  are  for  items  which  are 
not  of  a  military  nature  and  are  therefore  not  maintained 
within  the  supply  system. 

Material  acquisition  is  initiated  by  the  submission 
of  a  properly  prepared  DD  1  348  or  DD  1149.  These  documents 
must  have  been  properly  screened  by  the  Comptroller  for 
purposes  of  obligating  funds  for  payment,  and  they  must  have 
been  reviewed  by  personnel  in  I ss ue/P.eceipt  Control  for 
possible  'filling'  by  way  of  'standard'  stock.  If  either  of 
these  actions  is  incomplete,  they  are  returned  for  appro¬ 
priate  action  and  further  procurement  action  is  suspended. 
Visible  evidence  of  appropriate  action  is  certified  by  the 
appearance  of  the  Comptroller's  stamp  in  the  upper  right 
corner  of  the  document  and  a  date  stamp  on  the  oack,  accom¬ 
plished  by  Issue  Control  when  the  document  enters  the  Supply 
Department.  These  documents  must  contain  several  pieces  of 
information  without  which  procurement  action  cannct  be 
initiated: 

a.  DOCUMENT  NUMBER - r n is  number  consists  of  a  unique 

unit  identifier  code,  the  julian  date  upon  which  the 
req uisitio net  prepared  the  document,  and  the  requisi¬ 
tioned  s  next  sequential  serial  number.  This  number 


21 


must  be  unique  in  the  since  that  the  requisitior.ee  can 
identify  a  given  acquisition  from  all  other  acquisi¬ 
tions  given  only  this  number.  EXAMPLE: 

N12345-2180-1001 

b.  NOMENCLATURE - This  is  a  description  of  the  material 

or  service  which  the  requ isitioner  desires.  It  may  be 
formated  in  whatever  manner  the  requisitioner  wishes 
but  it  must  be  understandable  to  personnel  within  the 
Purchasing  Branch  and  must  contain  sufficiently 
explicit  information  to  facilitate  the  procurement. 
Such  things  as  size,  color,  tolerance  must  be  included 
tc  avoid  any  unnecessary  delays.  Of  particular  note  is 
the  need  for  SOLE  3 3 URCE  docuaertaf ion.  SOLE  SOURCE 
refers  to  the  requisi tioners  belief  that  the  material 
or  service  can  only  be  provided  by  a  particular 
vendor.  If  this  is  in  fact  the  case,  the  requisi- 
ticr.er  must  prepare  a  statement  sufficiently 
documenting  why  no  other  vendor  can  fulfill  the  need. 

c.  QUANTITY - The  amount  of  the  service  or  physical  good 

desired  by  the  requisitioner. 

d.  ESTIMATED  AMO  UNT-- -Th  e  dollar  anount/cost  of  the  goods 
c:  services. 

a.  REQUISITIONER - The  identification  of  the  order  .ng 

ur.it/department  which  is  to  receive  the  goods  or 
services. 

f.  PRIORITY-- -The  degree  of  urgency  associated  with  a 
given  acquisition. 

All  incoming  requests  are  screened  by  the  supervisor 
for  degree  of  difficulty  and  dollar  amount.  After  deter¬ 
mining  these  factors,  the  supervisor  assigns  each  request 
based  upon  the  level  of  knowledge  of  each  buyer  and  to  some 
degree  the  type  of  request  involved,  e.g.  imprest  fund 
requests  and  maintenaace/rer.t al  agreements  ace  typically 
assigned  to  particular  buyers  on  a  permanent  basis.  This 
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allocation  process  is  largely  subjective  and  is  based  upon 
the  supervisor’s  experience  and  knowledge  of  existing  back¬ 
logs  on  the  desks  of  individual  buyars. 

Each  buyer  receives  thair  assigned  acquisition 
requests  once  a  day,  or  possibly  twice  a  day,  depending  upon 
tha  supervisor's  ability  to  screen  his/her  incasing  basket. 
These  newly  assigned  requests  are  logged  into  the  buyer's 
work-in-progress  log.  This  log,  and  the  individual  entries 
contained  within  the  log,  will  subsequently  be  utilized  to 
produce  a  weekly  backlog  and  aging  report  for  use  by  tha 
supervisor  in  the  future  assignment  af  new  requisitions. 

The  order  in  which  each  buyer  processes  assigned 
requisitions  is  primarily  dependent  upon  the  priority  asso¬ 
ciated  with  each  requisition  and  secondarily  upon  the  age. 
It  is  important  to  r.ota  that  the  workload  and  the  priority 
system  do  at  times  combine  to  inhibit  the  tiaaly  processing 
of  lower  priority  requisitions,  i.a.  it  is  possible  for 
older,  low  priority  requisitions  ta  remain  unwarked  simply 
because  newly  received  requisitions  are  of  higher  priority. 
At  these  times  the  supervisor  is  responsible  for  identifying 
critical  cases  in  which  law  priority  requisitions  must  be 
given  preference  over  high  priority  raq uisitior.s.  when  this 
occurs,  the  supervisor  is  in  reality  tasked  with  accom¬ 
plishing  the  completion  of  bota  aged  low  priority 
requisitions  and  the  timely  processing  of  ail  high  priority 
requisitions  as  well.  In  short,  an  increase  in  productivity 
is  mandated.  A  delay  in  processing  results  in  a  degradation 
of  the  'procurement  action  lead  time'  (? ALT)  attributed  to  a 
given  requisition.  The  P\LT  measurement  is  a  key  indicator 
of  system  performance  utilized  by  every  purchasing  activity. 
This  indicator  measures  the  'wait  time'  experienced  on  every 
procurement  request  between  the  time  it  enters  the 
Purchasing  Branch  until  a  ouyer  has  contacted  a  vendor  and 
completed  the  necessary  action  required  to  initiate  the 
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actual  supply  of  the  material  or  service.  Such  a  measure- 
meat  is  closely  related  to  buyer  backlog  and  the  workloads 
upon  each  individual  buyer.  However,  the  PALT  measurement 
is  also  effective  as  an  indicator  of  overall  system  perform¬ 
ance  and  not  just  the  performance  of  a  single  buyer.  This 
measurement  is  now  being  provided  manually  on  every 
procurement  completed  to  determine  the  average  PALI  for  the 
system.  It  is  a  meaningful  indicator  of  branch  performance 
which  management  relies  upon  for  productior./planning 
purposes.  The  proposed  system  will  compute  this  information 
internally  and  provide  a  detailed  analysis  on  each  buyer  and 
on  the  system  as  a  whole. 

C.  AN  ALGORITHM  POR  NON-STANDARD  PRD CtJREMENTS 

The  following  discussion  is  Logically  organized  to 
provide  a  framework  by  which  a  given  procurement  transaction 
is  processed.  An  attempt  has  been  made  to  structure  the 
discussion  along  algorithm ic  lines  to  facilitate  an  under¬ 
standing  of  the  processes  each  buyer  must  utilize  when 
processing  a  single  transaction. 

1 .  Procurement  cf  AD?  Egui  pment 

The  first  decision  that  each  buyer  must  make, 
regarding  the  processing  of  a  requisition  is  whether  or  not 
a  given  acquisition  is  for  AD?  egaioment/service .  If  so, 
the  buyer  must  determine  from  the  estimated  price  whether  or 
not  the  sum  total  of  this  acquisition  will  exceed  $1  0,000. 
If  it  aces,  the  procurement  must  first  be  approved  by  the 
Chief  of  Naval  Education  and  Training  (CNET) .  The  buyer 

begins  this  process  by  completing  a  2276  and  legging  the 
transaction  in  the  Purchase  Support  Log.  This  log  consists 
of  the  following  columns: 

a.  Julian  date  on  the  r e guisi tione r 1 s  request 

b.  Serial  number  on  the  requ  isitioner  •  s  request 
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c.  Next  sequential  numoer  in  the  log 

d.  Date  transaction  is  being  logged 

e.  Department  code 

f.  Nomenclature 

g.  Activity  to  which  this  action  is  being  referred  for 
procurement 

h.  Number  of  different  line  items  being  procured 

i.  Dollar  amount 

j.  Contract  number  assigned  by  procuring  activity 

Opon  completion  of  the  2275,  in  is  forwarded  tc  the 
Chief  of  Naval  Education  and  Training  (CNET)  for  procurement 
authorization,  and  no  further  action  is  taken  pending  its 
return.  Ultimately  all  approved  requests  will  be  forwarded 
to  NSC  Oakland  for  action. 

2.  Procurem  ents  from  D  ther  Government  Agencies 

If  the  procurement  is  for  AD?  equipment/service ,  but 
will  not  exceed  $10,000,  or  if  the  procurement  is  not  for 
ADP  equipment/  services,  the  buyer  will  begin  procurement 
action  by  determining  whether  the  items  requested  can  be 
provided  by  some  source  within  the  federal  government,  e.g. 
the  Government  Printing  Office,  Federal  Prisons  Industry, 
etc.  Where  possible,  these  sources  are  utilized  to  minimize 
costs  tc  the  Government.  Acquisitions  from  these  Government 
Agencies  are  accomplished  on  an  1155  Delivery  Drier  citing  a 
locally  prepared  contract  number.  This  contract  number  is 
sequentially  assigned  fron  the  *F’  log  and  is  unique  to  each 
procurement.  The  'F*  log  is  composed  of  the  following 
col umns: 

a.  Julian  date  of  requisi tioner • s  request 

b.  Serial  number  of  requisitioner ' =  request 

c.  Next  sequential  number  in  the  log 

d.  Date  transaction  is  logged  in 

a.  Department  code 
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f.  Nomenclature 

g.  Vendor  is  local  or  oat  side  the  local  area 

h.  Tenant  activity 

i.  Dollar  amount 

3 .  Federal  SugBil  Schedule  Pthturements 

If  the  material/service  is  not  available  from  agen¬ 
cies  of  the  federal  government,  the  buyer  must  determine 
whether  it  can  be  procured  on  an  existing  contract 
previously  established  by  the  General  Services 
Administration  (GS&) .  These  contracts  are  referred  to  as 
Federal  Supply  Schedules  (FSS>  and  must  be  utilized  when 
available.  As  in  the  previous  example,  a  Delivery  Order  is 
prepared  citing  the  vendor  with  which  the  Government  has 
contracted  to  provide  the  given  goods/services.  However, 
the  FSS  number  will  be  cited  on  this  Delivery  Order  as  well 
as  the  local  purchase  order  number.  is  in  the  above  example 
this  transaction  will  be  loggsi  to  tie  log. 

4.  E£22’:i£i!!L§!l£.§  Exceed  _inq  £25,  3  22.  1  Limitation 

If  a  given  aguisition  cannot  be  f:_  led  by  a 
Government  source  or  cannot  be  provided  or.  an  existing  ?ss 
contract,  the  buyer  must  next  determine  whether  the  goods/ 
services  can  be  procured  for  less  than  $25,000.  This  is  the 
current  limitaticn  of  local  procurement  authority  and  is  the 
determining  factor  as  to  whether  a  given  aquisition  can  be 
contracted  locally  or  must  be  referred  to  another 
contracting  authority  having  a  higher  limitaticn.  For  those 
items  in  which  the  estimated  dollar  value  exceeds  this 
limitation,  the  buyer  will  prepare  a  2276  and  log  the  trans¬ 
action  ir.  the  Purchase  Support  Log.  Further  procurement 

action  at  the  local  leveL  is  suspended  and  the  activity  to 
which  the  action  is  referred  will  ultimately  provide  the 
Purchasing  Branch  with  a  copy  of  the  completed  contract. 
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5.  Procurements  Lass  Than  $500 

At  this  point  in  tie  processing  algorithm,  the  buyer 
should  have  eliminated  procurements  in  excess  or  325,000. 
In  order  to  continue  the  buyer  must  next  determine  whether 
the  sum  total  of  the  aqaisition  will  exceed  3500,  for 
competitive  bidding  processes  are  required  for  acquisitions 
exceeding  this  amount. 

First,  let's  consider  the  case  in  which  no  competi¬ 
tion  is  required,  i.e.  the  cost  of  this  transaction  will  not 
exceed  3500.  The  buyer  has  two  potential  means  of 
fulfilling  this  acquisition  request,  and  if  this  transaction 
does  not  exceed  $150  a  third  option  is  also  available. 

a.  1155  Purchase  Order 

The  buyer  may  prepare  an  1155  Order  for  Supplies 
or  Services  by  selecting  a  vendor  from  the  Small  Business 

Index  file.  This  file  has  been  established  in  Federal 

Supply  Class  (F SC)  order  to  facilitate  such  assignments, 
i.e.  it  is  arranged  by  type  of  material  supplied  by  the 
vendors.  Each  vendor  may  have  more  than  one  index  card  in 
the  file  if  he/she  supplies  a  wide  range  of  material. 

b.  Blanket  Purchase  Agreement 

The  buyer  may  select  a  vendor  with  whom  a 

Blanket  Furchase  Agreement  (BFA >  has  been  negotiated.  This 
type  of  acquisition  is  by  far  the  least  costly  to  process  in 
that  the  vendor  has  agreed  to  post  all  orders  to  an  open 
account  and  provide  a  single  itemized  bill  on  a  monthly 
basis.  There  are  two  possible  options: 

(1)  The  vendor  agrees  to  provide  material  based  solely 

upon  a  phone  request  from  the  Purchasing  Branch.  In 
this  case,  the  buyer  will  pass  the  order  to  the  vendor 
over  the  phone  and  will  provide  the  vendor  with  the 
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5PA  number  and  a  sequential  eaL  1  number  extracted  from 
the  *  A  *  section  of  the  1 F '  Log.  To  document  this 
transaction  the  buyer  will  prepare  a  DD  1348. 

(2)  The  vendor  requires  a  hard  copy  document  prior  to 

processing  the  order.  In  this  case  the  buyer  will 
prepare  a  4270  citiig  the  BPA  number  and  a  sequential 
call  number  extracted  from  the  'A'  section  of  the  'F' 

log.  The  original  is  provided  tc  the  vendor  to 

initiate  the  procurement. 

c.  Imprest  Fund 

In  those  cases  in  which  the  cost  doss  not  exceed 
$150  and  the  vendor  is  lot  a  BP A  vendor,  the  buyer  may 
process  the  acquisition  as  an  Imprest  Fund  order.  This  type 
of  procurement  is  like  that  of  a  petty  cash  transaction  in 
the  civilian  sector,  i. e.  the  requisit ioner  is  provided  with 
cash  to  pay  for  the  material  or  service  and  is  obligated  to 
return  a  paid  sales  voucher  to  the  Imprest  Fund  Cashier,  or 
the  vendor  may  agree  to  provide  the  material  TOD.  If  the 
vendor  will  accept  a  telephone  order  a  DD  1343  is  prepare! 
to  document  the  transaction.  If  is  requires  a  hard  copy 
document  a  4270  is  prepared  and  mailed  or  hand  carried.  In 
either  case  the  transaction  is  logged  in  the  * Y *  leg  which 
contains  the  following  columns: 

(1)  Julian  date  on  requis itio ner* s  requisition 

(2)  Serial  number  cn  r equ isit ione r’ s  requisition 

(3)  Current  date 

(4)  Next  sequential  number  in  *Y*  log  series 

(5)  UIC  or  department  of  requisitions! 

(6)  Description  of  item 

(7)  Vendor's  name 

(8)  Large  or  small  business  indicator 

(9)  Dollar  amount 
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6.  Procurements  Excea  1  ing  $5  OD 

Now ,  let*s  return  to  the  rase  in  whin  the  cost  of 
the  acquisition  will  exceed  $510.  At  this  point  rhe  buyer 
knows  that  the  cost  will  be  between  5500  and  $25,000.  This 
is  the  range  in  which  the  buyer  is  required  to  solicit  three 
or  more  competitive  bids  or  accept  the  submission  of  a  ’sole 
source'  statement  from  the  requisi tioner  justifying  the 
existence  of  a  single  acceptable  vendor.  Sole  source  is  the 
exception  rather  than  the  rule  and  nusr  be  closely  scruti¬ 
nized  with  a  view  toward  promoting  competition  as  opposed  to 
diminishing  it.  The  burden  of  providing  the  buyer  with 

adequate  sole  source  justification  is  on  the  requisitioned 
All  subsequent  processing  is  handled  in  the  same  manner  for 
both  sole  source  and  competitive  bidding,  i.e.  once  the 
ultimate  vendor  has  beau  determined,  completion  of  the 
acquisition  process  is  identical. 

7 .  Blanket  Purchase  Agreements 

The  buyer  may  proceed  by  determining  whether  a 
particular  acquisition  may  be  fulfilled  by  a  BP  A  vendor  (See 
previous  explanation  of  3?A  process).  This  is  accomplished 
by  determining  two  things: 

a.  Whether  the  total  cost  cf  the  acquisition  is  less  than 

$10,000. 

b.  Whether  the  vendor  in  question  has  negotiated  a  3PA 
agreement. 

If  the  answer  to  both  taese  questions  is  yes,  then  5PA 
processing  procedures  as  previously  discussed  are  fully 
applicable. 
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8*  Purchase  Orders  and  Purchase  Support  Procedures 

If  it  is  determined  that  tie  cost  of  acquisition 
will  exceed  the  $10,003  limitation  associated  with  3PA 
procurements,  a  check  aust  again  be  made  to  determine 
whether  the  cost  will  also  exceed  the  $25,030  local 
contracting  authority.  tf  so,  the  buyer  is  precluded  from 
issuing  an  1155  Purchase  Order  and  must  prepare  a  2276 
Reguest  for  Contractual  Procureaent.  As  previously 
discussed,  this  transaction  is  in  effect  a  referral  cf  the 
acquisition  process  to  an  activity  with  a  higher  contracting 
authority.  The  Purchase  Support  Log  is  used  to  document 
this  transaction.  In  tie  event  that  the  acquisition  in 
question  does  not  exceed  $25,000  the  buyer  is  authorized  to 
prepare  a  standard  1155  Purchase  Order  and  document  the 
transaction  by  legging  it  to  the  'S'  log.  This  log  consists 
of  the  following  columns: 

a.  Julian  date  on  requisi tioner' s  requisition 

b.  Serial  number  on  requisitioned  3  requisition 

c.  Current  date 

d.  Next  sequential  number  in  the  ' 1*  log  series 

e.  OIC  or  department  identification  number  of  requisi- 

tioner 

f.  Description  of  material 

g.  Vendor’s  name 

h.  Number  of  items  on  this  order 

i.  Vendor’s  locality 

j.  Dollar  amount 

Returning  again  to  the  question  of  whether  a  given 
acquisition  may  be  filled  by  a  BPA  vendor,  the  final  issue 
is  whether  the  vendor  being  considered  has  negotiated  a  5P A 
agreement.  If  not,  the  ouyer  has  no  option  but  to  complete 
the  acquisition  by  preparing  an  1155  Purchase  Order  as 
previously  discussed. 
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The  preceeding  sections  regarding  the  current 
processing  procedure  were  quite  long  and  rather  complicated. 
The  following  is  a  capsuLized  summary  cf  the  major  catego¬ 
ries  of  transactions  discussed: 

1.  Purchase  Orders - These  are  contractual  agreements  up 

to  $25/000,  which  are  prepared  on  an  DD  1155.  Those 
under  $500  do  not  require  competitive  bidding  prior  to 
award.  Those  above  $503  do  require  a  minimum  of  3 
competitive  bids  except  as  noted  ir.  the  chapter  on 
material  acquisition. 

2.  Blanket  Purchase  agreements  (BPA) - These  types  of 

transactions  are  in  affect  a  form  of  charge  account 
established  by  written  agreement  with  specific  vendors 
who  have  agreed  to  furnish  material  or  service  or. 

account  and  provide  an  aggregated  bill  on  a  periodic 
basis.  A  contractual  agreement  already  exists  at  the 
time  a  buyer  receives  the  procurement  for  action. 

3.  Imprest  Fund— -These  types  of  transactions  are  similar 

to  a  petty  cash  transaction  in  the  civilian  sector. 
Material  may  be  ordered  by  telephone  or  mail  for 

delivery  COD,  or  tae  r eguisition er  may  be  provided  with 
cash  to  pick-up  material  at  the  vendors  place  of  busi¬ 
ness. 

4.  Orders  Under  Contract— -Transactions  cf  this  type  are 
affected  utilizing  contracts  previously  negotiated  by 
another  activity.  A  typical  example  might  be  the  use  of 
a  Federal  Supply  3ci edule  (F53>  or  standing  contract 
negotiated  by  a  higher  authority.  These  may  be  referred 
to  as  a  Delivery  Drier. 

5.  Maintenance /Rental  Agreement - These  transactions 

involve  the  establis a ment  of  an  open  contract  (typi¬ 
cally  long  term)  in  which  the  vendor  aarees  to  provide 
a  piece(s)  of  rental  equipment,  and/or  service 
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specifically  denoted  piece(s)  of  equipment  for  a  nego¬ 
tiated  sum  cf  money. 

5.  Agreement  with  Civilian  Jniversity - These  agreements 

are  negotiated  with  various  civilian  universities  to 
provide  for  the  educational  services  they  offer  to 
government  employees  pursuing  courses  of  study  at  those 
institutions,  e.g.  tuition,  thesis  expenses,  etc. 

7.  Purchase  Support  r ransaction s - These  transactions 

involve  procurements  which  exceed  the  small  purchase 
limitation  of  $25,300.  Such  transactions  are  referred 
to  other  activities  having  authority  to  procure 
material  and  service  in  excess  of  this  amount. 

D.  MISCELLANEOUS  PROCESSING  CONSIDER ATIONS 

The  processing  procedure  cited  throughout  the  preceedir.g 
scenario  is  sufficient  to  process  95£  of  all  transactions 
entering  the  Purchasing  3ranch.  The  remaining  5*  of  all 
transactions  fall  into  a  wide  range  of  categories.  Two  of 
the  more  significant  warrant  recognition: 

1.  Minority  6 usinesses - This  category  includes  vendors 

who  belong  to  memoers  of  minority  races  or  even 
minority  groups  such  as  nomea-ovned  businesses.  Such 
businesses  enjoy  significant  advantages  over  others 
because  they  are  guaranteed  fi’-st  consideration. 
Simply  stated,  they  are  assure!  of  ucvernnent  business 
if  it  can  be  reasonaoly  assumei  that  tbev  can  fulfill 
the  needs  of  the  regu isitioner  and  if  the  cost  of  the 
material  or  service  is  reasonaole.  Such  vendors  need 
not  provide  the  material  or  service  at  the  absolute 
lowest  cost. 

2.  Small  Business  Set-asides - Procurements  of  this  nature 

exist  to  promote  smaLl  businesses  by  diminishing  the 
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competitive  forces  within  ths  market  place  with  which 
these  businesses  must  cops.  This  has  been  accomplished 
by  ’setting  aside’  specific  types  of  procurements  with 
specific  dollar  limitations  which  may  only  be  awarded 
to  small  businesses  under  the  auspices  of  the  Small 
Business  id ministratio n.  To  qualify  for  consideration 
in  this  program,  a  ousiness  must  have  a  limited  number 
of  employees  and  annual  sales  of  less  than  a  certain 
dollar  amount.  In  essence,  this  has  resul-ed  in 
limited  competition  between  a  few  qualifying  vendors  by 
precluding  larger  vendors  who  might  otherwise  enjoy  an 
•unfair'  economic  advantage. 

These  special  categories  are  nor  within  the  scope  of 
routine  processing  because  of  a  socio-political  ’awareness' 
atmosphere  within  the  3aited  States  which  has  prompted 
Congress  to  authorize  these  exceptions  to  the  competitive 
process.  Such  exceptions  have  been  recognized  as  being  ’in 
the  national  interest',  and  have  as  a  goal  the  enhancement 
of  the  social  and  political  welfare  o?  the  disadvantaged. 
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III.  PROPOSED  5 1ST EM  SPECIFICATIONS 


A.  BACKGROUND 

Typically,  a  proposal  system  is  founded  on  a  global 
process  view  which  requires  end-to-end  analysis  of  all  the 
activities  composing  the  process  as  well  as  those  which  are 
directly  affected  by  the  process.  This  analysis  has  two 
objectives: 

1.  The  possible  redesign  of  the  process  as  a  whole  and/or 
of  its  constituent  activities,  and 

2.  The  analysis,  integration,  evaluation  and  functional 
design  of  the  support  facilities  required  for  the 
various  activities  which  will  constitute  the  process. 

This  macro  analysis  view  of  the  process  may  dictate 
modifications  in  individual  activities  or  re-assignment  of 
activities  and  responsibili ties--since  it  makes  no  sense  to 
automate  and  perpetuate  au  unsatisfactory  process.  Even 
good  processes  may  need  redesign  to  fully  realize  the  poten¬ 
tial  of  new  technology,  and  this  is  entirely  the  case  at 
hand.  As  previously  stated  in  the  section  on  Scope  and 
Limitations  in  Chapter  I,  the  author's  proposed  MIS  design 
was  to  address  the  functional  responsibilities  of  the 
purchasing  activity  as  they  are  currently  assigned.  Indeed, 
re-structuring  of  functional  responsibilities  among  the 
various  branches  of  the  Supply  Department  was  to  be  avoided. 
This  aspect  of  the  author's  charter  has  curtailed  complete 
optimization  of  system  performance  in  that  the  purchasing 
function,  as  it  is  organizationally  defined,  does  not 
include  status  follow-up  responsibilities  or  invoice  certif¬ 
ication  and  payment.  The  incorporation  of  these  functional 
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responsibilities  would  facilitate  tie  development  of  ether 
forms  of  management  information  and  greatly  enhance  the  cost 
effectiveness  of  the  system.  For  example,  the  vendor 
selection  process  could  benefit  greatly  from  feedback  infor¬ 
mation  available  subsequent  to  material  receipt  and 
inspection.  Feedback  loops  might  be  established  whereby 
punctuality  and  merchandise  quality,  could  be  monitored  op. 
all  vendors.  Feedforward  information  to  receiving  personnel 
would  facilitate  the  process  of  material  identification  in 
the  receiving  area  and  improve  management  control  of  'frus¬ 
trated*,  undeliverable  material.  A  similar  feedforward 
mechanism  could  be  employed  to  alert  invoice  certification 
personnel  of  the  receipt  of  material  and  thus  provide  a 
'tickler  file'  of  work  in  process.  Such  a  system  would 
preclude  delays  in  invoice  certification  by  highlighting  the 
lose  of  receipt  paperwork. 

Obviously  the  scope  of  any  system  can  continue  to  be 
broadened  almost  indef in i tely ,  but  at  some  point  such 
systems  cease  to  be  purely  informational  in  nature  and  begin 
to  take  on  the  role  of  transaction  processing  systems.  As 
stated  previously,  this  was  not  the  intent  at  the  outset  of 
this  study.  The  author  has  therefore  tried  to  design  a 
system  which  provides  oily  management  information.  The 
criteria  utilized  to  decompose  the  existing  system  and 
develop  output  reports  £o:  management  purposes  are  depicted 
in  Table  I  The  data  elements  which  must  be  captured  to 
provide  this  information  will  be  discussed  in  a  subsequent 
section. 


B.  STSTEH  ORGANIZATION 

The  proposed  system  is  composed  of  a  logical  compilation 
of  t rar.sactions  which  document  the  various  steps  in  the 
procurement  lifecycle.  As  a  given  procurement  request 
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TABLE  I 

System  Development  Criteria 


1.  Types  of  Procurements 

2.  Method  of  Procurement 

3.  Contractor  Size 

4.  Procurement  Action  Lead  rime 


5.  Work-in-Process 

6.  Aged  Backlogs 

7.  Referrals 

8.  Customer  Mix 


evolves  from  the  initial  entry  phase  to  the  assignment  of  a 
solicitation  number  and  the  eventual  award  of  a  contract, 
its  progress  will  be  documented  utilizing  specially  designed 
transaction  coded  input  to  capture  each  change  in  life  cycle 
state.  System  input  will  be  edited  and  stored  for  daily 
batch  updating  of  the  data  base  since  there  is  no  need  for 
real-time  updating  or  on-line  query  capability.  Additional 
discussion  of  this  aspect  of  the  system  will  be  provided  in 
separate  section  referring  to  the  update  process.  A  series 
of  application  programs  must  be  designed  to  perform  the 
above  functions  and  provide  the  necessary  output  reports. 

1 .  Input 

The  proposed  system  will  accept  input  via  a  single 
programmable  CRT  terminal  capable  of  input  edit  functions 
and  forms  generation.  This  terminal  will  be  located  in  the 
Purchasing  Branch  and  will  be  utilized  to  establish  the 
initial  record  of  each  procurement  request  and  to  update 
each  record  with  new  information  developed  as  a  result  of 
the  procurement  process.  The  initial  record  of  each  requi¬ 
sition  entering  the  system  will  be  input  by  a 
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control-clerk/typist  utilizing  a  unique  transaction  cod si 
entry.  Appendix  A  contains  the  information  associated  witr. 
this  input  transaction.  It  is  in  essence  a  skeletor.iz-^ 
record  containing  only  the  barest  essentials.  However, 
foremost  among  these  essentials  is  the  assignment  of  a 
specific  buyer  who  is  responsible  for  the  *  cr  adie-to-gra  ve' 
processing  of  the  requisition.  This  key  element  will  be 
utilized  extensively  to  establish  responsibility  for  a  given 
procurement  and  to  provide  a  sort  key  for  aany  of  the 
proposed  output  reports. 

As  a  given  transaction  progresses  through  the 
procurement  process,  its  life  cycle  will  be  documented  at 
each  significant  change  in  state.  Following  initial  entry 
into  the  system,  a  specific  buyer  will  begin  the  task  of 
procuring  the  needed  material.  As  discussed  in  the  previous 
chapter,  this  is  a  complicated  process  subject  to  many  rules 
and  regulations.  Depending  upon  the  type  of  aaterial,  the 
dollar  value  of  the  procureaent,  and  the  existence  of 
purchase  agreements  with  numerous  venders,  the  ultimate  path 
to  receipt  of  material  may  be  quits  variable.  However,  this 
entire  process  can  be  captured  utilizing  six  transaction 
codes  to  represent  the  various  stages  of  *he  procurement 
process.  Table  II  contains  a  brief,  general  purpose 
description  of  each  of  the  these  transaction  codes.  A 
detailed  discussion  is  provided  in  subsequent  sections. 

As  stated  previously.  Input  is  accomplished 
utilizing  a  programmable  CRT  terminal,  and  due  to  the  rela¬ 
tively  small  volume  involved,  a  single  terminal  will 
suffice.  This  single  terminal  will  provide  each  buyer  with 
a  skeletonized  display  of  the  particular  transaction  code 
he/she  wishes  to  enter  simply  by  typing  ir.  the  desired  code 
number.  All  required  and  all  optional  ata  entries  relating 
to  a  specific  transaction  code  wouLi  be  clearly  depicted  on 
the  CRT  screen,  and  alL  input  typed  on  the  CRT  screen  wouli 
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TABLE  II 

Suaaary  of  Transaction  Codes 


CODE  SINERAL  PURPOSE 

1  Establish  a  newly  received 

requisition  in  the  system 

2  Assign  solicitation  number 

3  Assign  contract  number  and 

complete  procurement  record 

4  Make  selected  changes 

5  C anca 1  a  requisition 

6  Refer  requisition  to  another 

procurement  activity 


be  clearly  visible  to  the  person  inputting  the  information. 
Any  errors  would  be  readily  apparent  to  the  user.  Actual 
input  into  the  data  base  would  not  occur  as  an  immediate 
result  of  key  entry  on  the  terminal.  At  the  rime  of  key 
entry,  all  data  provided  oy  the  user  would  be  edited  by  the 
programmable  microprocessor  resident  inside  the  terminal. 
Invalid  entries  would  cause  the  entire  transaction  tc  be 
rejected  for  immediate  correction  by  the  person  who  input 
it.  This  procedure  insures  that  alL  input  is  accurate  with 
regard  to  format  and  data  type.  It  also  greatly  enhances  to 
probability  of  correction  and  resubmi. ssion  of  invalid  input. 

According  to  Gessford,  "The  decentralization  of  data 
input  operations  and  the  integration  of  data  input  into  the 
job  routines  of  the  user  group  has  in  some  cases  reduced  the 
cost  and  improved  quality  at  the  same  time,  contradicting 
the  apparent  cost-quality  trade-cff  concept  and  showing  the 
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overriding  importance  of  employee  motivation....  each  data 
input  system  should  be  controlled  and  operated  by  user 
personnel,  not  by  a  centralized  key-entry  department.  This 
means  that  data  input  systems  should  be  built  on  telepro¬ 
cessing  systems  that  include  terminals  at  user  locations. 
The  old  centralized  batch  system  in  which  users  submit 
typed,  or  handwritten,  documents  to  a  centralized  keypunch 
department  does  not  give  the  user  sufficient  control  over 
input  data  errors  made  by  that  department.”  [fief.  1  : 
p.  1  37  ].  Given  the  relatively  small  volume  of  transactions 
to  be  entered  (approximately  twenty  per  buyer  per  day),  the 
author  is  in  full  agreement  with  3es3ford5s  input  strategy. 
By  coupling  this  strategy  with  the  enhanced  capabilities  of 
the  'intelligent'  programmable  terminal,  it  is  anticipated 
that  significant  improvements  in  error  detection  and  correc¬ 
tion  turn-around  times  are  possible. 

The  following  suosections  contain  a  more  detailed 
discussion  of  the  function  of  each  transaction  code  listed 
in  Table  II  Appendices  A  through  F  provide  further  guidance 
regarding  the  data  elements  applicable  to  each  code. 

a.  Record  Establishment 


In  the  proposed  system  each  requisition  would 
begin  the  procurement  process  by  being  loaded  into  the 
system  utilizing  a  'TCI'  transaction  code.  Only  the  very 
basic  elements  relating  to  each  requisition  would  be 
captured  at  this  point,  i. a .  the  document  number,  the  data 
received,  the  priority,  and  the  code  of  the  buyer  assigned. 
In  this  system  the  TCI  would  be  entered  by  a  clerk-typist 
utilizing  a  data  input/output  terminal.  This  input  function 
could  also  be  performed  utilizing  a  keypunch  machine  and 
cards  if  necessary.  However,  such  systems  have  become 
outmoded,  given  the  high  cost  cf  card  stock  and  the  expense 
of  renting  and  maintaining  mechanical  keyounch  and  card 
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reader  devices.  The  relatively  small  rental  expense  of  a 
terminal  and  the  on-line  edit  functions  which  they  can 
provide  makes  it  the  most  cost-effective  method  for  input¬ 
ting  information. 

b.  Completion  of  the  Procurement  Record 

Upon  completion  of  the  initial  input  process, 
utilizing  the  TCI  transaction  code,  the  clerk-typist  would 
forward  the  requisition  to  the  designated  buyer.  An  auto¬ 
mated  record  of  the  requisition  would  now  be  resident  in  the 
data  base  and  the  existence  of  the  procurement  action  in  a 
buyer's  backlog  would  be  visible  to  the  supervisor.  In 
addition,  the  Procurement  Action  Lead  Time  (PALT)  'clock' 
would  begin  running  at  the  time  the  TCI  was  entered.  At 
this  juncture  the  buyer  would  be  responsible  for  all  further 
processing.  Table  II  depicts  the  various  options  available 
to  the  buyer.  Typically,  for  transactions  amounting  to  less 
than  $500,  the  buyer  would  select  a  vendor  and  enter  a  ' TC3 ' 
transaction  code  via  the  terminal  thereby  completing  the 
procurement  process.  For  procurements  exceeding  $500,  the 
buyer  would  enter  a  TC2  documenting  the  solicitation  of  bids 
from  various  vendors  and  updating  the  transaction  record 
with  the  solicitation  numoer.  Following  the  responses  from 
the  vendors  and  the  selection  of  the  winning  vendor,  the 
buyer  would  enter  a  TC3  to  complete  the  procurement.  During 
all  phases  of  the  life  cycle  of  a  given  procurement,  the 
supervisor  and  buyer  could  be  provided  with  hard  copy  prog¬ 
ress  reports.  More  appropriately,  they  should  be  provided 
with  daily  exception  reports  listing  those  procurements 
which  exceed  expected  processing  tin ef ramss.  Such  reports 
would  warrant  close  scrutiny  by  the  supervisor  to  better 
establish  priority  processing  efforts  for  the  workforce. 
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c.  Referrals 

In  addition  to  routine  processing  utilizing  TCI, 
TC2  ana  TC3  entries,  the  buyer  mignt,  depending  upon  the 
money  value  or  special  nature  of  the  procurement,  be 
required  to  refer  the  requisition  to  another  purchasing 
activity.  These  procurements  would  be  entered  utilizing  a 
TC5  transaction  code  and  would  document  the  Unit 
Identification  Code  (UIC)  of  the  new  activity  having 
procurement  responsibility.  As  these  activities  issue 
contracts  in  fulfillment  of  their  responsibilities,  they 
are  required  to  forward  information  copies  to  the  initiator 
of  the  request.  These  copies  would  be  received  by  a  clerk- 
typist  and  entered  into  the  MI3  utilizing  a  TC3  to  document 
completion  of  the  procurement.  Again,  exception  reporting 
on  overaged  referrals  should  be  generated. 

d.  Changes  and  Cancellations 

TCI,  TC2,  TC3  and  TCS  transactions  compose  what 
would  be  termed  'standard  processing  procedure'.  However, 
some  facility  must  be  built  into  the  proposed  SIS  to  allow 
for  changes  or  cancellations  to  procurements  previously 
entered  into  the  system.  The  TC4  and  TC5  have  been  proposed 
for  these  purposes.  The  TC4  transaction  cods  provides  the 
buyer  with  the  capability  to  change,  by  overlaying,  all 
previously  input  information  except  the  original  document 
number  provided  by  the  customer.  To  change  the  document 
number,  assuming  it  was  entered  in  error,  the  buyer  would 
first  have  to  cancel  the  erroneous  record  utilizing  a  TC5 
cancellation.  The  correct  document  number  would  then  be 
re-entered  utilizing  a  new  TCI  entry.  This  double  input 
procedure  is  proposed  as  a  safeguard  to  preclude  the  inad¬ 
vertent  alteration  of  correct  TCI  entries.  Any  buyer  who 
wished  to  correct  an  erroneous  document  number  would  be 
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required  to  input  two  separate  translations.  T&e  IC5  cancel¬ 
lation  would  require  the  positive  selection  and  input  of  a 
reason  code  for  the  cancellation.  In  addition,  each  TC5 
entry  would  generate  a  detailed  cancellation  listing  for 
supervisory  information. 

2 .  Dpdate 

As  proposed  by  the  author,  the  new  SIS  will  be 
updated  on  a  daily  basis  with  the  validated  input  discussed 
in  the  preceeding  section.  The  update  process  would  utilize 
an  application  program  designed  to  post  input  transactions 
to  a  master  file  containing  information  on  all  active  and 
completed  procurements  not  yet  purged.  New  records  would  be 
opened  in  the  file  for  newly  recei/ed  procurements.  New 
information,  documenting  a  change  in  an  already  existing 
record,  would  be  added  to  the  file.  It  is  important  to  keep 
in  mind  that  this  information  has  already  been  validated  for 
errors  in  format  during  the  input  process  and  the  user 
should  not  expect  many,  if  any,  update  errors. 

The  system  has  oeen  designed  as  a  batch  update 
system  after  careful  analysis  of  the  daily  business  routine. 
The  author  found  no  evidence  that  real-time  updating  cf  the 
data  base  is  necessary.  This  is  true  primarily  because  of 
the  processing  procedure  already  in  use  whereby  a  single 
buyer  has  *cra dle-to-grav e*  control  of  each  individual 
procurement.  Given  the  relatively  small  number  of 
transactions  being  processed  during  the  day,  any  inquiry 
regarding  a  given  requisitions  status  is  easily  answerable 
if  a  change  has  recently  occurred.  Procurements  for  which 
no  change  in  status  has  taken  place  will  be  accurately 
reflected  on  the  previous  days  output  reports.  Information 
regarding  the  status  of  procurements  as  of  the  preceeding 
day  is  considered  mors  than  adequate  for  workload  and 
backlog  analysis  purposes.  Real-tias  updating  of  the  data 
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base  ana  on-line  inquiry  capaoilities  are  totally  unneces¬ 
sary  and  will  only  add  to  the  cost  and  maintenance  problems 
associated  with  the  system. 

As  in  any  system,  the  correct  sequencing  of 
transactions  is  paramount  to  the  successful  posting  of 
input.  In  the  propose!  system,  sequencing  will  be  accom¬ 
plished  on  two  levels.  First,  only  one  buyer  will  be 
responsible  for  the  'cradle -to-grave'  processing  of  a  given 
procurement  after  its  initial  entry  into  the  system.  This 
should  insure  a  degree  of  continuity  to  the  input 
transactions  in  that  a  buyer  would  not  logically  attempt  to 
complete  a  procurement  without  first  opening  a  record  for 
the  procurement.  Likewise,  a  buyer  would  not  logically 
attempt  to  refer  a  procurement  to  another  activity  if  the 
contract  had  been  awarded  locally.  To  preclude  human  error 
in  which  this  logical  procedure  might  be  violated,  a  second, 
positive  control  feature  would  be  incorporated  in  software 
to  insure  the  proper  sequencing  of  transaction  codes  when 
used  in  conjunction  with  a  batch  uplate  procedure.  Table 
III  depicts  the  proposed  priority  for  processing  the  various 
transaction  codes  into  the  system.  Input  data  would  be 
physically  sorted  prior  to  posting  to  insure  compliance  with 
this  table. 

The  update  process  discusse!  thus  far  pertains  to 
the  updating  of  the  data  oase  with  new  information.  However, 
as  in  any  system  some  means  of  purging  inactive,  completed 
procurements  from  those  still  active  and  pending  procurement 
action  is  required.  The  author  proposes  a  monthly  purge  of 
the  master  record  file  in  which  all  records  containing  a  TC3 
or  TC5  entry  are  deleted  from  the  master  record  and  moved  to 
a  history  file  of  completed  procurements.  Both  the  TC3 
completion  and  the  TC5  cancellation  would  be  considered 
end-of-work-in-process  inputs,  and  by  moving  such  records  to 
a  history  file  the  inexorable  growtn  of  the  master  record 
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file  would  be  precluded.  Given  the  1,030  new  procurement 
requests  each  month  and  tie  need  to  prepare  periodic  hard¬ 
copy  reports  of  all  active  procurements,  this  purge  process 
seems  most  appropriate.  This  is  especially  true  in  light  of 
the  considerable  number  of  sort  passes  which  will  be 
required  to  produce  tailored  listings  by  buyer  cods  and 
document  number.  It  is  absolutely  imperative  if  the  system 
is  to  remain  compatible  with  microcomputer  technology. 

C.  REPORT  GENERATION 

The  proposed  MIS  is  basically  a  monitoring  tool  designed 
to  record,  track  and  document  tns  receipt,  progress  and 
award  of  purchase  requests.  It  originates  when  the  requisi¬ 
tion  is  first  received  in  the  Purchasing  Branch  and  is 
continuously  updated  by  the  buyer  to  reflect  the  most  recent 


TABLE  III 

Transaction  Code  Processing  Priority 


PROCESS 

PRIORITY 


CODE 


status  of  each  procurement  request.  Once  recorded,  the 
requisition  is  monitored  through  the  buying  cycle.  when  a 
solicitation  number  is  assigned,  tie  system  is  updated.  When 
referral  actions  are  taken  or  revisions  are  made  che  system 
is  updated,  and  when  the  requisition  is  awarded  or  cancelled 
the  system  is  updated.  Each  of  these  updates  are  reflected 
in  hard  copy  output  reports  designed  to  provide  management 
and  individual  buyers  with  information  regarding  their 
performance.  To  assist  in  the  analysis  of  these  reports  a 
detailed  description  of  data  elements  contained  within  them 
is  provided  in  Appendix  G. 

1  •  Daily  Re  ports 

As  proposed,  the  system  would  generate  most  reports 
on  a  request  basis.  That  is,  to  request  a  report,  the  user 
would  simply  enter  a  special  report  identifier  code  into  the 
batch  update.  Naturally,  some  reports  would  be  requested 
more  frequently  than  others.  The  following  subsections 
describe  the  daily  reports  produced  oy  the  system. 

a.  Daily  Listing  of  Update  Transactions 

The  Daily  Listing  of  All  Update  Transactions 
would  generate  a  hard  copy  of  all  transactions  entered  in 
the  update.  It  would  be  output  automatically  without 
request.  This  listing  would  becoms  a  permanent  record  of 
ali  transactions  processed  in  a  gi/en  update  and  thereby 
provide  an  audit  trail  and/or  means  of  identifying  and 
correcting  transactions  wiich  may  have  been  entered  errone¬ 
ously.  It  would  appear  as  an  33/33  image  of  the  input 
transaction.  A  typical  daily  update  would  contain: 

(1)  48  transactions  to  establish  new  records 

(2)  9  transactions  to  establish  solicitation  numbers 

(3)  48  transactions  to  establish  contr act/order  numbers 

(4)  8  transactions  to  document  caanges  no  existing  records 
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(5)  1  cancellation  transaction 

(6)  1  referral  transaction 

b.  Detailed  Listing  of  Active  Procurements 

This  listing  contains  a  detailed  record  of  all 
procurement  requests  currently  held  in  the  system.  It  is  in 
document  number  sequence  and  provides  the  user  with  a  means 
of  cross-referencing  specific  procurements  to  the  buyer 
assigned.  Currently  no  such  system  exists.  Based  upon 
monthly  receipts  of  1,303  new  requisitions  and  an  average 
PALT  figure  of  13  days,  this  Listing  would  generate  approx¬ 
imately  1624  lines  of  output.  See  Figure  3.1. 

c.  Daily  Summary  of  iiork  Processed/Current  Backlog 

Repo  rt 

The  Daily  Suamary  of  Work  Processed/Curr ent 
Backlog  Report  would  contain  a  suamary  of  the  previous  days 
work  and  the  current  backlog.  It  would  present  aggregated 
totals  only  and  would  not  address  individual  buyer  statis¬ 
tics.  See  Figure  3.2. 

d.  Daily  Completio ns/CanceL Lat ions  Report 

The  Daily  Completions/Cancellaticns  Report  would 
be  sorted  by  buyer  code  and  would  contain  a  total  count  by 
buyer  of  all  IC3  and  TC5  transactions  posted  during  the 
update.  It  would  also  list  the  totaL  number  of  new  receipts 
by  buyer.  See  Figure  3.3. 

e.  Daily  Customer  Mix  Report 

The  Daily  Customer  Mix  Report  would  provide 
information  on  individual  customers.  It  would  be  sorted  by 
UIC  for  external  commands  and  by  document  serial  number  for 
internal  departments  and  divisions.  This  report  would  list 
the  total  number  of  procurement  actions  received  from  each 
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List i a 2  of  Act! vs  Procurements 
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DOC  SLCT  CONT  DAI E  B  DATE  DATE  RESP  UIZ  PR 

NUH  NDM  NtJM  PHI  RECD  C  CDMP  REF  D  DOE  REFD  ESD  TYPE 


« - 

Figure  3.1 

Detailed  Listing  of 

Active  Procurements. 

Daily  Sum  mar y  of 

WDE.il  Process 

ed/Current  Backlog 

REQN  RECD 

REQN 

AWARDED 

REQN  SOLICIT 

TOTAL  CANC 

REQN 

BACKL03 

—  • 

Figure  3.2  Daily  Summary  of  fork  Pcocessed/Current  Backlog 

customer,  each  customer's  percentage  of  the  total  workload 
volume,  the  total  number  of  procurements  awaiting  completion 
by  customer,  each  customer's  percentage  of  the  total  volume 
awaiting  completion  and  the  average  PALT  by  customer.  See 
Figure  3.4. 

f.  Daily  Work-in  Process  Report 

The  Daily  Work-in-Process  Report  will  be  a  prin¬ 
ciple  working  document  depicting  each  buyer's 
workload/backlog  status  in  detail.  Its  primary  sort  would  be 
by  buyer  code.  Within  buyer  code  each  transaction  would  be 
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Figure  3.3  Daily  Coip letions/Tiacallations  Report. 


«  ■ 

telly  Oust 

o  mer 

;iix  Report 

:■ 

REQN 

% 

TOT  % 

UIC 

ESCD 

R  E2  N 

RE2N  RE^N 

PALT 

■ 

04629 

55 

96 

303  94 

20 

Pi 

05119 

2 

4 

20  6 

ii 

L-"-. 

TOTAL 

57 

100 

320  100 

\> 

L  _ 

i  • 

c-y 

L 


h  . 


i* 


i: 


r« 


Figure  3.4  Daily  Customer  Mix  Report. 

listed  by  document  number  together  with  the  date  it  was 
received,  the  priority,  the  solicitation  number,  the  date 
referred  if  applicable,  and  the  anticipated  referral 
response  date  if  applicable.  At  the  bottom  of  each  buyer's 
portion  of  the  report,  an  aggregated  total  of  all 
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Dai  1 1  Work  in  Process  Report 


B  DOC  SOLT  DATE  DATE  REE  P 

C  NUM  NUM  RECD  REFD  DOE  PRI 

BOYER  TOTAL  EXCEEDING  30  DAYS  OLD:  XXX 
BOYER  TOTAL  PROCORE  SENT  S  REFERRED:  XXX 


Figure  3.5  Daily  Work  in  Process  Report. 

transactions  exceeding  30  days  old  and  an  aggregated  total 
of  all  referrals  should  be  displayed.  This  listing  would 
average  624  lines  in  length  oased  on  a  13  day  PALI.  See 
Figure  3.5. 

g.  Report  of  Purchase  Transactions  on  Referral 

The  Report  of  Purchase  Transactions  on  Referral 
is  a  detailed  list  of  alL  active  referrals  (TC3  or  TC5  not 
posted)  sorted  ty  document  number.  It  contains  the  buyer 
code,  the  date  received,  ti e  date  referred,  the  anticipated 
response  date  and  the  priority.  See  Figure  3.6. 

2.  Honthix  Reports 

Equally  important,  but  Less  frequently  required, 
would  be  information  designed  to  assist  management  ir.  the 
preparation  of  external  as  well  as  internal  reports  to 
superiors.  Typically,  these  reports  deal  with  longer  term 
analysis  and  are  used  for  long  term  production  and  planning 
purposes.  The  following  reports  would  be  provided  on  a 
monthly  basis  or  more  frequently,  if  desired. 


Daily  Purchase 

Transactions  on  Referral 

DOC  B  DATE 

DATE  RESP 

NUM  C  RECD 

REFD  DCJE  PRI 

TOTAL  FOR  THIS  31 

C:  XXC 

Figure  3.6  Daily  Purchase  Transactions  on  Referral. 

a.  Monthly  Customer  Mix  Report 

The  Monthly  Customer  Mix  Report  is  similar  to 
the  Daily  Customer  Mix  Report  discussed  ir.  the  previous 
section.  However,  it  would  contain  an  aggregation  of  one 
month's  transactions  as  its  name  implies. 

b.  Monthly  Comp  lat  ions/Canca  nations 

The  Monthly  Completion/Cancellation  Report  would 
be  similar  to  the  daily  report  discussed  in  the  previous 
section.  It  would  contain  a  monthly  aggregation  by  buyer 
code  and  in  addition  would  be  secondarily  sorted  by  purchase 
type  in  recognition  of  the  different  production  rates 
attributable  to  each  type  of  procurement,  i.e.,  some  types 
of  purchases  are  easier  to  effect  than  others.  See  Figure 
3.7, 

c.  Monthly  Referral  Analysis  Report 

The  Monthly  Referral  Analysis  Report  would 
provide  management  with  information  regarding  the  rate  at 
which  each  specific  customer’s  reguests  are  referred  to 
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Figure  3.7  Monthly  Completions/Oancellations  Report. 
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other  purchasing  activities  for  action.  It  would  be  sorted 
in  customer  order  and  would  contain  the  total  number  of 
requisitions  awaiting  action  by  a  referral  activity,  the 
total  number  of  requisitions  held  in  the  system  (referrals 
plus  ncn-refarra Is)  ,  and  a  percentage  referral  rate  deter¬ 
mined  by  dividing  the  former  by  the  latter.  See  Figure  3.8. 
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d.  Monthly  PALI  Report 
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The  Monthly  PALT  Report  will  be  key  indicator  of 
purchasing  performance.  This  report  will  be  stratified  by 
purchase  order,  delivery  order,  imprest  fund,  BPA  and 
contracts.  It  will  list  the  montaly  total  of  completed 
procurements  under  these  headings.  In  addition,  the  PALT 
for  each  of  these  headings  would  be  listed  by  computing  the 
difference  between  the  date  cf  receipt  and  the  date  of 
completion  on  each  transaction.  Sea  Figure  3.3. 

e.  Monthly  DD  1  057  Report 


The  Monthly  DO  1057  Report  is  a  summary  of  all 
transactions  of  $10,000  or  less.  It  is  stratified  into 
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Monthly  Referral  Analysis 
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Figure  3.9  Sonthly  PALT  Report. 

method  and  purchase  type.  For  purposes  of  the  proposed 
output  report,  the  output  data  should  be  listed  by  lire  item 
corresponding  to  the  appropriate  line  on  the  actual  DD  1057. 
Each  line  would  contain  a  total  for  the  actual  number  of 
reguisitions  processed  to  completion  (TC3)  during  the  month, 
and  a  total  dollar  value  for  the  month.  See  Figure  3.10. 
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Figure  3.10  Monthly  DD  1357  Report. 

f.  Monthly  NAVSUP  Fora  83  Report 

The  Monthly  NAVSU?  Fora  83  Report  would  contain 
purchase  statistics  for  use  by  the  Naval  Supply  Systems 
Command.  Like  the  DD  1057  report  previously  discussed,  it 
would  stratify  purchases  according  to  various  headings  and 
subheadings.  Each  line  of  the  actual  report  has  a  unique 
number  associated  with  it  for  automated  reporting  purposes. 
Some  of  the  headings  and  subheadings  are  small  purchase  by 
procurement  type,  purchases  referred  to  other  activities, 
non-competitive  purchases,  FALT,  beginning  work,  in  process, 
receipts,  cancellations,  completions,  and  ending  work  in- 
process.  The  proposed  MI5  is  designed  *o  assist  management 
by  captu- ing  the  data  elements  necessary  to  automatically 
generate  the  total  count  and  dollar  value  associated  with 
each  of  these  headings.  See  Figure  3.11. 
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Monthly  NAVSOP  Form 

80  Report. 

g.  Monthly 

Histo 

ty  Report 

The  Monthly 

History  Report 

would  contain  a 

detailed  listing  of 

all 

completed  or  cancelled  procurements 

purged  from  the 

syst 

aa  during  the 

montaly  update. 

Appearance  on  this  1 

1st  in 

g  would  mark  the 

end  of  the  trans- 

action  life  cycle. 

and 

as  such  would  warrant  retention  of 

this  listing  for  audit  trail  purposes.  This  Listing  would 
contain  approximately  1,150  lines  of  output  each  month.  See 
Figure  3.12. 

D.  DATA  ELEMENT  SELECTION 

The  identification  of  specific  data  elements  needed  in 
an  information  system  is  deduced  by  studying  the  information 
needs  of  management.  This  information  when  transformed  to  a 
machine-readable  form,  and  organized  according  to  prescribed 
conventions  is  called  a  data  base.  The  contents  of  the 
proposed  data  base  is  really  the  result  of  considerable 
analysis  of  the  work  site  and  the  routine  processing  proce¬ 
dure.  The  information  it  contains  has  been  screened  against 
the  myriad  of  possible  data  elements  associated  with  the 
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Figure  3.12  Monthly  History  Report. 

purchasing  process  and  fauna  to  nave  a  highly  positive 
correlation  with  the  type  of  information  which  procurement 
managers  need.  Primarily,  it  contains  all  the  data  elements 
necessary  for  external  reporting  purposes,  however,  it  also 
provides  additional  elements  of  particular  interest  at  the 
local  level,  e.g.  buyer  code,  reason  for  cancellation, 
referral  QIC,  etc.  Each  cf  the  elements  is  absolutely 
necessary  to  the  proper  functioning  of  the  proposed  system 
and  are  required  for  the  production  of  the  proposed  output 
reports.  To  assist  in  the  development  of  the  data  base  and 
to  avoid  misinterpretation  of  data  elements,  a  data  element 
dictionary  (DED)  has  been  incorporated  into  Appendix  G. 

Analysis  of  the  work  site  and  the  manual  processing 
procedures  revealed  the  existence  of  broad  areas  in  which 
management  control  can  be  enhanced.  The  primary  problem 
facing  management  is  a  lack  of  timely  information  regarding 
the  real-time  state  of  the  Purchasing  Branch.  That  is,  the 
supervisor  is  only  aware,  in  any  positive  sense,  of  the 
inputs  to  the  system  and  lacks  daily  production  and  backlog 
information  with  which  to  analyze  the  efforts  cf  individual 
buyers.  This  is  true  because  of  the  labor  intensive  nature 
of  most  data  collection  systems  and  the  demand  which  they 
place  upcn  scarce  productive  resources.  The  single  control 
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system  currently  in  use  is  a  local  form  completed  by  each 
buyer  on  every  procurement.  Known  as  a  Supply  Department 
Purchase  Statistics  Form,  it  is  composed  of  a  series  of 
boxes  which  the  buyer  annotates  to  reflect  the  categories 
pertaining  to  a  given  procurement.  The  data  elements 
contained  on  the  form  are  those  necessary  for  external 
reporting  purposes  and  thus  have  direct  application  tc  the 
type  of  management  information  developed  within  the  propcsel 
automated  MIS.  With  only  slight  modification,  this  form 
will  be  ideal  for  use  in  conjunction  with  the  proposed  MIS. 
The  data  elements  listei  on  the  form  cculi  be  easily 
augmented  with  the  balance  of  the  additional  elements 
contained  in  Appendix  3.  All  of  the  elements  required  by 
the  proposed  MIS  would  than  be  present  on  the  form.  This 
would  provide  each  buyer  with  a  written  record  of  each  of 
the  days  transactions,  which  could  taen  be  utilized,  at  the 
convenience  of  the  buyer,  for  key  entry  at  the  input 
terminal.  Continued  use  of  the  form  would  also  provide  a 
secondary  or  parallel  data  collection  mechanism  for  use  when 
and  if  the  automated  system  became  inoperable. 

The  quality  of  information  derived  from  any  data  base  is 
directly  related  to  the  gnality  of  tne  data  base  itself.  For 
this  reason  considerable  time  and  effort  have  been  expended 
in  the  selection  of  the  elements  which  it  contains.  With 
good  administration,  the  elements  found  ir.  Appendices  A 
through  G  will  provide  all  the  flexioility  needed  for  future 
development. 
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A.  I  SPOT 


Data  ir.put  is  critical  to  the  design  of  ary  system. 
According  to  3e  ssf  ord,  the  success  of  the  system  depends 
upon  the  quality  of  input  data  as  defined  by  accuracy, 
completeness  and  timeliness.  These  three  attributes  must  be 
properly  integrated  to  insure  the  potential  acceptability  of 
the  output  module.  The  author  partially  addressed  the  issue 
of  data  completeness  in  a  prior  section  on  data  element 
selection,  wherein  the  key  elemets  impacting  upon  management 
decision  making  were  proposed  for  data  capture  (See  Appendix 
G) .  However,  any  discussion  of  completeness  must  also 
address  the  issue  of  input  requirements  imposed  by  the 
system  design.  In  short,  a  measure  of  input  volume,  as 
dictated  by  the  scope  of  the  proposed  data  elements,  is 
necessary  to  properly  'size*  the  system.  The  primary 
factors  impacting  upon  this  analysis  are: 

1.  The  number  of  transactions  to  be  processed 

2.  The  number  of  characters  per  transaction 

The  number  and  types  of  transactions  to  be  processed  have 
been  determined  by  survey  of  the  work  site.  The  number  of 
characters  input  for  each  type  of  transaction  is  computed  in 
Table  IV.  A  summary  is  provided  in  Table  V.  Admittedly,  such 
an  analysis  is  only  an  estimate,  but  it  is  sufficiently 
accurate  to  formulate  a  general  impression  of  the  relative 
hardware  requirements,  i.e.  microcomputer,  minicomputer  or 
max icomputer. 


TABLE  IV 

Monthly  Input  Requirement  Detail 


INPUT 


Reqn  Reed 
(TCI) 


Assign  Solicit 
Number 
(TC2) 


Contract  Award 
(TC  3) 


Selected  Changes 
(TC4) 


DATA  ELEMENT  CHARACTERS 

Service  Cole  1 
Document  Number  13 
Julian  Data  Reed  4 
Priority  2 
Buyer  Code  2 
Transaction  Code  1 


TDTAL  23 


Service  Code  1 
Document  Number  13 
Solicitation  Number  14 
Buyer  Code  2 
Transaction  Code  1 


TDTAL  31 


Service  Cole  1 
Document  Number  13 
Contract  Numoer  14 
Julian  Date  Completed  4 
Estimated  Delivery  Date  4 
Buyer  Code  2 
Contractor  Size  1 
Purchase  Type  1 
Unoriced  Purchase  Order  1 
Total  Price  7 
Purchase  Type  1 
Cob peti tion/N oncompetiti on  1 
Tr a  ns action  Code  1 


TDTAL  51 


Service  Code  1 
Document  Numoer  13 
Contract/Solicit  Number  14 
Priority  2 
Buyer  Code  2 
Estimated  DeLivery  Date  4 
Contractor  Size  1 
Purchase  Matnod  1 
Mod.  of  Dollar  Value  1 
Dollar  Value  7 
Unpriced  Purchase  Order  1 
Purchase  Type  1 
Competition  Code  1 
Transaction  Code  1 


TOTAL 
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With  regard  to  hardware,  it  should  be  apparent  that  many 
possible  combinations  of  input  components  exist.  Indeed,  no 
single  input  hardware  'package*  may  oe  ideal,  and  two  quite 
diverse  combinations  may  provide  the  same  level  of  marginal 
return. 


I  ABLE  IV 
{ Cont  *  d) 

Monthly  Input  Requirement  Detail 


INPUT 


DATA  ELEMENT 


CHARACTERS 


Cancellation 

(TC5) 


Service  Code  1 
Do  ument  Numoer  13 
Julian  Date  Cancelled  4 
Buyer  Code  2 
Reason  For  Cancellation  1 
Transaction  Code  1 


Referral 

(TC6) 


TDTAL  22 

Service  Code  1 

Document  Numoer  13 

UI Z  of  Referral  Act.  5 

Julian  Date  Referred  4 

Response  Due  Date  4 

Buyer  Code  2 

Transaction  Code  1 

f 


TDTAL 


30 


TABLE 

V 

I 

Summary  of 

Total 

Monthly 

Inpat  Requirements  j 

INPUT 

TRANSACTION/ 

MONTH 

CHARACTER/ 

TRANSACTION 

TOIAL 

CHARACTER 

Regr.  Reed 

* 

o 

o 

o 

23 

23,000 

Assign  Solict 

175 

31 

5,425 

Contract  Award 

1 ,000 

5i 

51,000 

Changes 

150 

50 

7,500 

Cancellations 

10 

22 

220 

Referrals 

11 

30 

330 

TOTAL 

2346 

37,475 

Hare  again  the  concept  of  system  design  is  relegated  to  a 
series  of  *rade-offs  which  must  0=  quantified  in  tarms  cE 
overall  system  performance.  The  resilcar.t  integration  inva¬ 
riably  retains  an  element  of  subjectivity. 


B.  OUTPUT 

The  output  function  is  the  most  visible  portion  of  any 
HIS,  and  without  it,  all  else  is  irrelevant.  Several 
options  are  available  to  the  designer.  The  two  most  common 
are  terminal  and  printer  output.  Each  has  advantages  and 
disadvantages.  For  purposes  of  the  proposed  system,  a  slow 
line  printer  or  even  slower  serial  printer  would  provide 
hard  copy  output  quickly  and  at  relatively  low-cost.  The 
principle  disadvantage  of  hard  copy  output  is  the  volume  of 
bulky  paper  reports  which  must  be  filed.  To  partially 
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alleviate  this  problem,  the  author  proposes  that  hardcopy 
reports  be  generated  only  on  request.  CRT  terminal  output 
is  more  convenient  but  his  limited  display  capacity  and  no 
hard  copy  capability  to  provide  for  long  term  access  or 
audit  trail  maintenance. 

The  output,  as  proposed,  consists  of  seven  daily  and 
seven  monthly  report  listings.  This  volume  is  not  large  in 
terms  of  overall  system  capacity,  i.e.  data  access/retrieval 
time,  buffer  capacity,  print  time,  etc.  For  this  reason 
many  hardware  options  remain  open  to  the  user.  In  order  to 
permit  evaluation  of  these  alternatives,  output  requirements 
are  estimated  in  lines  and  characters  and  are  exhibited  in 
Table  VI  and  Table  VII  As  evidenced  by  these  requirements 
and  those  in  Tables  IV  and  V,  tae  size  of  the  system  is 
still  within  the  scope  of  a  large  mior ocomputer  system. 

C.  STORAGE 

In  assessing  the  storage  requirements  of  the  system, 
consideration  must  be  given  to  storage  volume,  access  time 
and  the  record  format  being  utilized.  The  latter  factor  is 
heavily  dependent  upon  the  progressing  language  and  the 
skills  of  the  individual  programmer.  As  proposed  by  the 
author,  this  system  would  be  implemented  in  COBOL  or  a 
similar  language  wherein  a  continuous  fixed  length  record  is 
established  for  each  requisition  wiich  enters  the  system. 
The  file  of  records  would  be  logicaLly  arranged  in  document 
number  sequence  and  each  transaction  affecting  a  given 
record  would  merely  post  to  the  appropriate  field  of  the 
record  or,  in  the  case  of  changes,  overlay  already  existing 
information.  More  elaborate  file  structures  are  common 
today  utilizing  data  base  management  systems  (DErtS)  ; 
however,  the  relatively  small  size  of  this  system  and  the 
few  number  of  users  does  not  warrant  the  large  expense  of 


multiple  file  types  or  a  DBMS.  According  to  Hussain  [Ref.  2 
:  p.204],  as  much  as  500,  000  characters  of  main  memory  may 
be  necessary  to  support  a  DBMS,  and  three  times  more  extra 
disk  memory  is  required  for  a  DBMS  than  for  an  MIS  without  a 
DBMS.  As  stated  in  the  opening  remarks,  low  cost  is  a 
factor  in  the  system  design.  lo  renain  within  the  scope  of 
microcomputer  technology  consideration  of  a  D3M3  is  inappro¬ 
priate.  Such  a  system  would  require  all  of  the  main  memory 
just  to  support  the  DBMS,  and  depending  upon  file  structure, 
the  memory  requirements  of  the  data  base  itself  could 
conceivably  be  increased.  According  to  Hussain,  a  DBMS  is 
generally  indicated  when  a  firm  needs  at  least  three  of  the 
fol lowing : 

1.  An  integrated  data  environment 
v 

2.  Rapid  retrieval  of  data  from  large  files 

3.  A  query/update  language  for  use  at  terminals 
'4.  Sophisticated  backup  and  recovery  procedures 
5.  Elaborate  privacy/security  protection 

5.  Handling  of  complex  lata  structures. 

Since  the  proposed  system  does  not  meet  any  of  the  above 
criteria,  the  author  has  elected  to  use  the  traditional 
application  programming  package  (APPi  approach.  That  is  , 
"...A  system  of  computer  programs. .. tnat  formulate  routine 
data  requests,  supply  the  requests,  input  and  edit  new  data, 
update  existing  data,  calculate  and  summarize  data,  and 
produce  various  output  documentation  all  in  its  own  peculiar 
fashion.  The  data  items  in  storage  are  organized  in  a 
manner  that  makes  sense  for  the  particular  application" 
[Ref.  1  :  p.96].  Given  the  range  of  the  proposed  reporting 
system,  considerable  sorting  of  the  naster  data  file  will  be 
necessary  which  will  ma<e  the  system  quite  sensitive  to 
access  times  and  volume. 


TABLE  71 

Analysis  of  Daily  Qutpat  Reports 


LINES 

CHARAOT 

ERS 

OUTPUT 

DATA 

0/ E  RHD* 

TOTAL 

PER  LINE 

TOTAL 

Update  Trans 

Reqn  Reed 

48 

3 

4  8 

23 

1104 

Solicit. 

9 

0 

9 

31 

279 

Contracts 

48 

3 

48 

51 

2448 

Changes 

8 

0 

8 

50 

400 

Cancel. 

1 

0 

1 

22 

22 

Referrals 

1 

3 

1 

30 

30 

Active 

Procurements 

1624 

24  3 

1857 

72 

134424 

Work 

Processed 

2 

1 

3 

52 

156 

Completion/ 

Cancelled 

5 

1 

5 

26 

156 

Customer 

MiX 

60 

9 

59 

21 

1449 

Work  in 

Process 

624 

94 

713 

44 

31592 

Trans  on 

Referral 

1  1 

1 

12 

30 

360 

TOTAL 

244  1 

349 

2793 

172420 

♦Headings,  Totals,  etc. 
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Analysis  of  Monthly  Output  Reports 


LIMES 

CHARACT 

ERS 

OUTPUT 

DATA 

OVERHD* 

TOTAL 

PEP  LIME 

TOTAL 

Customer  Mix 

60 

9 

59 

21 

1449 

Complt/Canc 

30 

4 

3  4 

19 

646 

Refferal  Anal. 

60 

9 

59 

15 

1035 

PALT 

5 

1 

5 

10 

60 

DD  1057 

47 

7 

54 

15 

810 

NAVSUP  FORM  80 

36 

5 

41 

14 

574 

History  Rpt. 

1000 

150 

1150 

67 

77050 

TOTAL 

1238 

195 

1423 

81624 

♦Headings,  Totals,  Etc. 


Any  storage  device  installed  in  the  system  mast  provide 
sufficient  capacity  to  store  all  lata  which  need  to  be 
stored,  and  it  must  be  aole  to  access  the  data  in  a  time 
frame  consistent  with  the  application  under  consideration. 
The  storage  requirements  for  the  proposed  system  are  exhib¬ 
ited  in  Table  VIII. 

As  proposed  by  the  author,  there  is  only  one  file  in  the 
system.  It  is  known  as  the  master  file  and  is  composed  of 
approximately  2000  fixed  length  records,  each  of  which  is  91 
bytes  in  length.  Each  record  in  the  file  is  known  as  a 
master  record  and  is  logically  arranged  in  document  number 
sequence  within  the  file.  Appendix  3  details  the  elements 
contained  in  each  master  record  and  provides  a  character 
count  by  element.  The  sum  total  of  all  characters  depicted 


T  A  BLE  VIII 

Monthly  Disk  Capacity  Requirements 


STORAGE 


FILE 


RETENTION  RECDRD  NUMBER  VOLUME 

CYCLE  LENS  TH  RECORDS  BYTES 


Master  Rec  1  month  9  1  bytes 


2000 


162,000 


ACCESS  TIME 

Assume  1  access  on  average  for  every  transaction 
input. 

Assume  1  access  on  average  for  each  line  of  output. 

(2346  Lines  I nput/Month)  X  1  Access  =  2,346 

(Table  V) 

(2790  Lines  Output/Dayl  X  21  Days  X  1  Acc.  =  58,590 

(Table  VI) 


(1423  Lines  Output/Month)  X  1  Access 
(Table  VII) 


1,423 


Total  Accesses/Month 


62, 353 


within  Appendix  G  is  90,  however,  the  author  has  elected  to 
add  an  additional  byte  of  data  in  Table  vm  to  allow  for 
flag  bits  needed  in  application  programming.  Each  master 
record  contained  on  the  master  file  is  therefore  91  byte- 
long. 


D.  SUMMARY 

The  possibilities  for  configuring  a  system  are  endless. 
It  is  useful,  therefore,  to  think  in  terms  of  standard 
classes  of  equipment  into  which  most  specific  items  fall 
quite  readily.  For  example,  storage  devices  may  be 
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categorized  by  speed  of  access  and  storage  volume  parame¬ 
ters.  Two  classes  of  disks  come  to  mind:  1)  me  floppy 
disk,  and  2)  the  hard  disk.  The  former  has  distinct  advan¬ 
tages  with  respect  to  portability  but  car.  not  approach  the 
access  speeds  and  totaL  storage  voLume  capacities  of  the 
hard  disk  drive.  These  broad  classes  of  devices  are  the 
kinds  of  decision  criteria  which  must  be  thoroughly 
researched  before  deciding  upon  specific  vendor  models. 

Before  proceeding  to  draw  conclusions  from  the  sizing 
analysis  conducted  in  the  previous  sections,  a  summary  of 
the  information  contained  in  those  sections  seems  appro¬ 
priate.  Table  IX  provides  the  reader  with  a  capsulized  view 


TABLE  IX 

Summary  of  Monthly  System  Requirements 


FUNCTION 

ES£UI5EMENT 

In  put 

8  7,4  75 

CP  M 

Output 

(21  Days) 

5  8,5  90 

LPM 

3,620,820 

CP  M 

(1  Month) 

1,423 

LPM 

or 

8  1,524 

CP  M 

Storage 

1  3  2,000 

BITS 

Accesses 

6  2,359 

*CPM  equals  C  haract ers/M  or.ta 
*L  PM  equals  Lines/Month 


255  CORR 

SCTION 

TOTAL 

21,353 

CPM 

109,344 

CPM 

14,547 

LPM 

73,237 

LPM 

or 

or 

3  05,205 

CPM 

4,525, 025 

CPM 

355 

LPM 

1,773 

LPM 

or 

or 

20,40  5 

CPM 

132,030 

CPM 

45,500 

BYTE 

227,500 

BYTE 

15,590 

77,949 

i 


As 


of  requirements  associated  with  the  proposed  system, 
stated  at  the  outset,  the  figures  determined  by  this  anal¬ 
ysis  are  estimates,  and  allowances  should  be  made  for 

unforeseen  errors,  potential  design  changes  and  growths  in 
volume.  Table  IX,  therefore,  contains  an  added  25%  safety 
margin  in  each  of  the  estimated  requirements. 

Giver,  the  data  depicted  in  Table  IX, it  is  now  possible 
to  determine  the  kind  of  system  which  is  suitable  for  the 
Purchasing  Branch  application.  As  in  all  of  the  previous 
discussion,  the  best  approach  is  to  attempt  to  answer  the 
questions  of  component  size  and  performance  characteristics 
by  subdividing  the  analysis  into  inpit,  output,  storage  and 
access  time. 

1 .  Input 

From  Table  IX,  we  know  that  some  109, 344  characters 
will  be  input  each  month.  Since  we  nave  previously  proposed 
to  capture  input  utilizing  a  single  programmable  terminal  it 
seems  apparent  that  some  analysis  of  the  capacity  of  the 
terminal  to  handle  this  workload  is  necessary.  Given  that 
the  average  rate  of  input  in  this  mode  is  about  200  charac¬ 
ters  per  minute,  some  547  minutes,  or  about  9. 1  hours  per 
month  will  be  required  for  data  entry.  An  additional  small 
fraction  of  this  time  (5, 'Si  could  also  be  expected  for  vali¬ 
dation  error  detection  correction  and  resubmission.  From 
these  figures  the  reader  can  now  be  reasonably  assured  that 
a  single  programmable  input  terminal  will  successfully 
handle  the  expected  volume  of  transactions. 

2 .  0 Ut£U t 

From  Table  IX,  it  is  known  that  75,016  lines  will  be 
output  each  month.  Since  the  proposed  system  will  rely  upon 
hard  copy  printed  reports  it  must  oe  determined  whether  a 
single  printer  or  multipLe  printers  will  be  required.  A 
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typical  line  printer  has  a  working  speed  of  130  lines  per 
minute.  Such  a  printer  would  dispose  of  the  expected 
monthly  workload  in  a  750  minutes,  i.e.,  about  12.5  hours 
per  month.  A  less  formidable  printer,  such  as  a  'daisy 
wheel',  can  print  at  approximately  55  characters  per  second. 
It  would  dispose  of  the  proposed  workload  in  approximately 
84,  146  seconds,  i.e.,  about  23.4  hours  per  month.  Giver,  the 
approximate  times  required  by  each  printer,  it  is  apparent 
that  either  will  suffice,  and  that  the  options  available  for 
the  proposed  system  are  not  constrained  by  print  times. 

3 .  Storage 

The  storage  requirements  depicted  in  Table  IX  are 
227,500  bytes.  Such  a  system  is  wall  within  the  bounds  of 
current  microcomputer  technology.  Indeed,  a  small  microcom¬ 
puter  equipped  with  a  single  floppy  disk  drive  would  provide 
adequate  secondary  storage  capacity  for  this  system.  As  for 
main  memory  capacity,  a  system  having  only  54,000  bytes 
would  mere  than  accommodate  the  operating  system  ana  any 
foreseen  application  programming.  Storage  capacity  alone 
however,  does  not  adequately  address  the  issue,  for  access 
time  plays  a  significant  role  ir.  the  selection  cf  storage 
devices. 

Table  IX  indicates  that  77,949  accesses  will  be 
required  each  month  to  support  the  input  ana  output  work¬ 
load.  Given  typical  average  access  times  of  309 
milliseconds  for  floppy  disks  and  37  milliseconds  for  hard 
disks,  access  time  per  month  would  come  to  about  6.5  hours 
for  the  floppy  and  1.9  a  ours  for  the  hard  disk  system. 
Either  of  the  two  disk  technologies  would  be  adequate  for 
the  proposed  system. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

The  purpose  of  this  study  has  been  to  develop  a  proposal 
foe  the  implementation  of  an  automated  Management 
Information  System  (MIS)  at  the  Naval  Postgraduate  School 
purchasing  activity.  To  accomplish  this  purpose,  a  survey 
of  operations  and  the  volumes  of  data  associated  with  those 
operations  was  conducted.  From  these  data,  the  input, 
output,  storage  and  memory  requirements  of  the  system  were 
derived.  A  brief  list  of  the  key  areas  and  issues  that  were 
developed  in  this  study  is  as  follows: 

1.  How  is  the  manual  processing  'system  organized  and  what 
functions  does  it  perform? 

2.  What  are  the  key  indicators  of  system  performance  upon 
which  management  reLies?  Can  additional  performance 
indicators  be  developed? 

3.  What  data  elements  must  be  captured  to  provide  the 
necessary  management  information? 

’U .  How  can  an  automated  system  be  developed  to  provide 
management  information? 

5.  How  »large'  would  an  automated  system  be? 

B.  CONCLUSIONS 

Conclusion  #1 

The  current  manual  information  collection  procedure 
within  tfre  Purch^s  ir.q  Branch  provides  only  the  assent  pal 
of  information  necessary  to  fulfill 

tXiisaidL  £§.£2.£ii.aa  aeanfsiseiifi* 
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The  rate  of  collection  and  analysis  of  current  informa¬ 
tion  does  not  provide  management  with  a  trusly  current 
picture  of  work  unit  performance.  Significant  management 
enhancements  are  possible  given  only  the  information 
currently  being  collected  by  the  manual  information  system; 
however,  this  would  require  adiitional  personnel  to 
organize,  collate  and  calculate  data  into  finer  levels  of 
granularity  than  is  now  possible.  The  development  of  an 
automated  information  system,  utilizing  much  the  same  input 
data  as  is  now  collected,  would  improve  management  control 
by  providing  daily  as  opposed  to  monthly  information.  An 
automated  system,  with  no  increase  in  manpower  (also  no 
decrease) ,  could  provide  additional  information  on  indi¬ 
vidual  buyer  production  and  backlog,  improve  visibility  of 
cancellations,  improve  determination  of  PALI  by  purchase 
type,  analyze  customer  mix  and  greatly  enhance  the  visi¬ 
bility  and  follow-up  on  procurement  referrals.  By  providing 
this  information  on  a  daily  basis  as  opposed  to  monthly, 
management  would  be  afforded  an  opportunity  to  plan  and  act 
in  a  real-time  mode  as  opposed  to  reacting  to  monthly  output 
statistics. 

Conclusion  #2 

An  automated  MIS  for  the  Purchasing  Branch  can  be  imple¬ 
mented  utilizing  microcomp j  ter  technology  if  desired. 

As  proposed,  the  MIS  for  the  Purchasing  Branch  is 
completely  autonomous,  i.  e.  there  is  no  interfacing  with 
extra-organizational  elements.  This  aspect  of  the  design 
has  made  possible  a  remarkably  small  system  with  none  of  the 
complications  which  are  generally  associated  with  larger 
integrated  data  bases  and  their  resultant  proliferation  of 
newer  and  ever  changing  output  requirements.  All  data 
elements  ir.  the  proposed  system  are  solely  'owned1  by  the 
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Purchasing  Branch.  This  fact,  together  with  the  snail  size 
and  few  number  of  output  applications  obviates  the  need  for 
a  data  base  management  system  (DBMS!  and  its  attendant  soft¬ 
ware  and  hardware  expenses.  The  result  is  a  system  which 
may  be  implemented  on  a  large  microcomputer  utilizing  tradi¬ 
tional  application  programming  techniques. 

C.  RECOHHENDATIOHS 

Throughout  this  study,  emphasis  has  been  placed  upon 
developing  a  system  to  meat  the  information  needs  of  manage¬ 
ment.  The  prime  constraint  associated  with  the  project  has 
bean  cost.  Fortunately,  the  system  requirements  to  meet  the 
needs  of  management  have  oeen  determined  to  be  relatively 
small,  and  the  result  has  been  little  or  no  trade-off 
required  between  output  quality  and  system  cost.  In  effect, 
both  goals  can  be  achieved  utilizing  existing  microcomputer 
technology. 

Before  making  specific  recommendations  regarding  the 
structure  of  the  proposed  system,  it  should  be  noted  that 
the  existing  facilities  at  the  UavaL  Postgraduate  School 
afford  a  unique  opportunity  to  system  developers.  Thar  is, 
the  existence  of  a  large  and  powerful  mainframe  computer 
facility  and  multiple  minicomputer  systems  on  the  campus. 
The  feasibility  of  developing  the  proposed  MIS  around  one  of 
these  systems  on  a  time  sharing  basis  should  be  examined 
before  attempting  to  procure  any  raicr ocomputer  components. 
Such  systems  offer  distinct  advantages: 

1.  Reliability  of  the  larger  system  is  better  than  that  of 
a  microcom purer,  and  maintenance  down-time  is  drasti¬ 
cally  improved  by  on-site  technicians.  Hardware 
maintenance  costs  could  be  reduced  through  negotiated 
maintenance  agreements  already  ir.  existence  on  the 
larger  equipment. 
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2.  The  larger  bus  structures  and  word  sizes  of  the  mini 
and  maxi  computers  <rould  improve  application  run-time 
significant ly. 

3.  Application  programs  for  updating  and  report  generation 

could  be  run  during  the  evening/night  by  full  time 
system  operators  ani  thus  maxe  more  rime  available 
during  the  day  for  buyer  personnel  to  enter  input. 
Indeed,  on  the  larger  machines  multiprogramming  could 
accomodate  data  entry  to  storage  ani  production 

programming  simultaneously. 

4.  The  high  level  languages  available  on  the  larger 

machines  are  more  programmer  efficient  and  would  tend 
to  decrease  application  programming  and  maintenance 
costs. 

Failure  to  adequately  explore  the  use  of  the  larger  hardware 
systems  would  eliminate  a  unique  oppcrtunity--one  which 
could  well  provide  first  rate  service  at  less  cost  than  a 
microcomputer  hardware  package. 


Recommendation  #1  -  3  ecu 

proposed  MIS  utilizing  the 


re  to  i mgl ement  the 

IBS  System  30  33  located  at  the 


Naval  Postgraduate  Schools  M.  R .  Church  Computer  Facility. 

Implementation  of  tae  proposed  MIS  utilizing  this 
facility  would  provide  the  advantages  discussed  above,  and 
would  decrease  the  hardware  aquisition  costs  dramatically  by 
requiring  only  the  rental  or  purchase  of  a  single  program¬ 
mable  terminal  for  key  entry  and  editing  of  input 
transactions.  This  terminal  would  be  located  in  the  offices 


of  the  Purchasing  Branch  f 
hard  wired  into  terminal 
Storage  wouid  be  accomolis 
ment,  and  output  would  be 


or  ease  of  access,  and  would  be 
controllers  for  the  System  370. 
hed  on  existing  IBM  disk,  equip- 
geaeratei  by  the  IBM  1403  line 


printers.  Development  o f  application  programming  utilizing 
an  ANSI  COBOL  compiler  would  afford  a  high  degree  of  upward 
compatibility  with  future  systems  waich  may  seek  to  inte¬ 
grate  ail  aspects  of  the  Supply  Department  and  Comptroller 
Department  into  a  single,  large  MIS  and  transaction  proces¬ 
sing  system. 


Recommendation  #2  -  If  r ego  mmenda ti on  #1_  is  not  possible  to 
Implement,  then  procure  a  micr ocoaput_er  system  with  a 
minim  urn  of  64,000  bytes  of  main  memory,  a  dual  disk  drive 
for  secondary  storage,  a  CRT  input  terminal  and  a  serial 
out  put  Erin ter. 

Microcomputer  technology  is  adequate  to  suppers  the 
proposed  system  and  would  require  very  little  investment. 
Disk  storage  could  be  accomplished  utilizing  either  floppy 
or  hard  disk  devices,  however,  the  author  recommends  the 
hard  disk  technology  since  it  typically  has  better  reli¬ 
ability  and  greater  storage  capacity  for  future  expansion. 
In  addition  the  author  recommends  that  a  dual  (two)  disk 
drive  system  be  procured  even  though  a  single  disk  would 
suffice.  This  will  allow  for  coping  of  disks  and  file 
transfer.  The  CRT  terminal  for  data  entry  need  not  be 
programmable  if  the  input  edit  function  is  built  into  the 
microcomputer,  however,  tie  forms  generation  capability  on  a 
programmable  CRT  terminal  would  greatly  improve  data  entry 
efficiency.  The  cost  trade-off  would  be  the  determining 
factor  for  this  component.  Output  requirements  associated 
with  this  system  are  relatively  smalL,  and  it  was  shown  that 
even  a  small  'daisy  wheel'  printer  could  handle  the  volume. 
A  line  printer  is  not  recommended.  Ar.y  reliable  serial 
printer,  compatible  with  the  other  components,  would  be 
suf  f icient. 
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It  is  important  to  note  that  the  use  of  a  microcomputer 
system  would  probably  involve  longer  periods  cf  down-time  in 
which  no  output  from  the  system  would  be  possible. 
Consequently,  it  is  strongly  recommended  that  a  parallel 
manual  system,  similar  to  that  proposed  for  raw  data  collec¬ 
tion,  be  maintained.  This  data  would  reguire  manual 
analysis  and  expenditure  of  manpower  only  when  the  automated 
system  was  disabled. 

As  with  any  microcomputer  system,  application  program¬ 
ming  and  maintenance  is  weak.  Choice  of  programming 
languages  are  limited  and  typically  are  not  as  programmer 
efficient  as  those  offered  on  larger  computer  systems.  It 
is  imperative  that  system  developers  select  a  language,  such 
as  COBOL,  which  will  offer  a  high  degree  of  upward  compati¬ 
bility  and  ease  of  maintenance  in  the  event  that  future 
developments  dictate  an  integration  of  the  proposed  system 
with  those  in  other  divisions  and  departments. 
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|P PEND IX  & 

TRANSACTION  CODE  1 - INITIAL  INPUT  OP  REQUISITION 


FIELD  SIZE£T2£S 
1/al pha 


DESCRIPTION 


Service  Code 

Note: 


13/numeric 

4/numeric 

2/numeric 

2/numeric 

1/numeric 


For  procurements 
initiated  by  the 
Naval  Postgraduate 
School  and  other 
shorebased 
activities  use  • N ' 


Document  Number  as  submitted  on 
requisition  by  requisitioner 

Julian  Date  Received 

Priority  Assigned 

Code  of  3uyer  Assigned 

Transaction  Code  must  be  • 1 • 


4 


4 
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4 


TRANSACTION 

FIELD  SI2E/TYP! 
1/alpha 

1  3/numeric 

1 4/alpha 
numeric 

2/numeric 


A P PEND I I  B 

CODE  2 - ASS  IGN8ENT  OF  SOLICITATION  NUMBER 


DESCRIPTION 


3  ERVICE  CODE: 

Note:  For  procurements 
initiated  by  the 
Naval  Postgraduate 
School  and  other 
shorebased 
activities  use  ' N* 


Document  Number  as  submitted  cn 
the  initial  transaction  code  ' 1* 
*  hich  estaolished  this  record. 


Solicitation  Number  assigned 
Note:  Sixth  character  must  =  alph 


Code  of  assigned  buyer 


1/numeric 


Transaction  Code  must  be  '2' 


TRANSACTION 

FIELD  SIZE/TYPE 
1/alpha 

1  3/numeric 

1  4/alpha 
numeric 

4/numeric 

4/numeric 

2/numeric 

1/aipha 

1/alpha 


APPENDIX  £ 

CODE  3 - CONTRACT  AWARD  AND  CDSPLETION 


DESCRIPTION 


Service  Code 

Note:  For  procurements 
initiated  by  the 
Naval  Postgraduate 
School  and  other 
shorebased 
activities  use  ' N' 


Document  Numoer  as  submitted  or. 
the  transaction  code  •  1  *  which 
established  this  record 


Or der/ Contract  Number  assigned 
Note:  Sixth  character  must 
CfH,A,F,Y  (to  dis- 
tmauish  contracts 
purchase  orders,  B 
imprest  and  delive 
orders) 


Julian  Date  completed 


Estimated  Delivery  Date 


Code  of  3uyer  assigned 


Contractor  Size 

Note:  Large  Business 
Small  Business 
Fduc/Non  orof it 
Minority1 Business 
Woman-Owned 


Pu rchase  Mshtod 

Note:  Neaotiated 

Formal  advertisir. 


1/alpha 


Unpriced  Purchase  Order 


1* 

APPENDIX  C  (Continued) 


FIELD  SIZE/TYPE 


DESCRIPTION 


7/numeric 


Total  Price 


1/alpha 


Purchase  Type 
Note: 


Contract 
Purchase  Order 
Imprest  Fund 
BP  A 

Delivery  Order 
Modification 


v  1 /alpha 

« 


Co  mpetition/Soncompetit io 
Note:  Competitiv 
Noncompeti 
Under  5500 
Orders  on  FSS 


1/numeric 


Transaction  Code  must  be  '3' 
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e  !•  it)  y 


iP PEND IX  D 


TB AMS  ACT I OH 

CODE  4 - SELECTED  CHANGES 

FIELD  SIZE/TYPE 

DES  CPIPTIOM 

1/alpha 

Service  Code 

Note:  Must  b®  identical 
to  the  r:i 

1  3/numeric 

Document  Number 

Note:  Must  be  identical 
to  TCI 

1  4/alpha 
numeric 

Ca angs  Order /Contract /Solicitation 
Mu  mber 

Note:  Sixth  character  must  =  alpha 

2/numeric 

Change  Priority 

2/numeric 

Buyer  Code 

4/numeric 

Change  Estimated  Delivery 

Date 

1/alpha 

Change  Contractor  Size 

Note:  Large  Business 

Small  Business 
Educ/Non profit 
Minority  Business 
Woman-Owned 

1/alp'na 

Change  Puroaase  Methgd 

Note:  Negotrated 

Formal  advertising 

1/alpha 

Modification  of  Dollar  Amount 

Note:  Increase  or  Decrease 

7/numeric 

Dollar  Amount 

1/alpha 


(Jn  priced  Purchase  Order 


APPENDIX  D  (Continued) 

FIELD  SIZE/TYPE 

DE3 CRIPTION 

1/alpha 

Change  Purchase  Type 

Nets:  Contract 

Purchase  Order 
Imprest  Fund 
BPA 

Delivery  Order 
Modification 

1/alpha 

Change  Competition  Code 

Note:  Competitive 

Noncompetitive 
Under  5530 
Orders  on  FSS 

1/numeric 

Transaction  Code  must  be  '41 

APPENDIX  E 

TRANSACTION  CODE  5 - CANCELLATIONS 


FIELD  SIZE/TYPE 
1/alpha 

1  3/numeric 


4/numeric 

2/numeric 

1/alpha 

1/numeric 


DE3 CRI»riON 

Service  Coda 

Note:  Must  match  TCI 
input 

Document  ttunber 

Note:  Must  match  TCI 
Input 

Julian  Data  Cancelled 
Code  of  3uye r  Assigned 
Reason  for  Cancellation 
Transaction  Code  must  ba  • 5 • 


SI 


IPPENDIX  P 

TRAHSACTICN  CODE  6 - REPERRAL  OF  A  REQUISITION 


FIELD  SIZE^TYPE 
1/alpha 

1  3/numeric 

5/numeric 

4/numeric 

4/numeric 

2/numeric 

1/numeric 


DESCRIPTION 


Meta:  Must  match  TCI 


Document  Number  as  submitted  on 
the  transaction  code  • 1  *  which 
astablishad  this  record 


UIC  of  Referral  Activity 


Julian  Data  Referred 


Julian  Data  Referral  Response 
due 


Code  of  Buyar  assigned 
Transaction  Code  must  d£  'S’ 
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APPENDIX  S 

DATA  ELEMENT  DICTIONARY 


Name  of  Data  Element 

|  Service  Code 

Variable  Name 

j  SVC  CODE 

Definition 


I  A  Designation  identifying  shorebased 

- +  activities  from  fleet  activities,  and 

Pacific  Fleet  from  Atlantic  Fleet  activities. 


Classification  1 
anc  Coding  | 

•  N*  equals  shorebased 

1  R'  equals  Pacific  Fleet 

*  V*  equals  Atlantic  Fleet 

Jses 

1 

Used  as  first  position  of  all 
document  numbers. 

Derivation 

Rule  i 

Source  is  NAVCOMPT  Manual 

Units 

1 

N/A 

Fermat 

1 

ALPHA  |  Justification  |  N/A 

Width  of  Field 

•  —  —————— ——————  —  —  >  • 

Validity  Rules  | 

- + 


1  character 


Editing 

input. 


- 4. 

I 

- + 


Require  d 

Range  j 

1 

Content  |  Other 

< 

XXXXXXXX 

T3D  | 

i 

1 

Option  a  1 

1  1 

1 

1 

1 

1 

1 

|  This  element  must  be  checked  by  edit 
♦  routine  upon  entry  of  all  types  of 


y  pes 


-+  • 

I 


Comments 


It  will  always  be 
number. 


This  element  will  aopear  on  the 
requisition  presented  bv  the  customer, 
in  the  first  position  of  the  document 


83 


APPENDIX  G  (Continued) 


— f  — ———————————————— 

Name  of  Data  Element  |  Document  Number 

-  - - - — - - f - - - — 

Variable  Name  I  DOC  HUM 

- 


Definition  I  This  is  a  unique  number  assigned  to  all 

- +  requisitions.  If  is  composed  of  the 

customer's  UIC  the  juliaa  date  and  serial  number  (as 
assigned  by  the  customer)  .  It  may  not  be  duplicated. 


Classif ication  1  N/A 
and  Coding  I 


Uses 


|  Used  to  identify  a  single  requisit: 
from  all  other  re quisitions. 


Derivation  Rule  j  Source  is  customer's 


Units  | 

1  N/A 

Format  1 

Width  of  Field  | 

1  Numeric  I  Justification  |  N/A 

|  13  digits 

j  Editing 


|  This  element  must  be  edited  on 

every  transaction  input  into  system 


Comments  j  This  element  will  be  provided  by  the 

- ♦  customer.  It  is  a  key  sort  element 

associated  with  many  output  reports. 


APPENDIX  G  (Continued) 


Name  of  Data  Element  |  Julian  Date  Received 

- ► - 

Variable  Name  I  DATE  RETD 

- + - f - 

Definition  i  Julian  date  on  which  the  orocurement 

- +  request  entered  the  purchasinc  branch. 


Classification  I  N/A 
and  Coding  ! 


- * - 

Jses  |  To  establish  beginning  of  ?ALT  cycle 

- ♦  and  aging  of  oaolclog. 


Derivation  Rule  |  This  date  will  be  entered  by  the 

- +  contra  L  cleric  a  d  a  n  submission  of  t  he- 

TCI  transaction  code  into  the  system. 


J  nits 
Fermat 


N/A 

Numsri c 


tfidth  of  Field  |  4  digits 


•  +  —  —  —  —  —  — —  —  —  —  +  —  —  —  —  —  - 

|  Justification  |  N/A 

-+ - + - 


Validity  Rules  |  Required 
— - ♦ 


XXXXXX  X 
Optiona 1 


Range 

TBD 


Content  |  Other 

I 


Editing 


>♦ - - 

|  This  element  mus! 
■+  transactions 


I 
I 

•  + - ♦ - 

I 

I 

I 

- ♦ - 

be  edited  on  all  TCI 


Comments 


- 4. . 

I 

- > 


APPENDIX  G  (Continued) 


APPENDIX  G  {Continued) 


APPENDIX  G  (Continued) 


Name  of  Data  Element 

- 

1 

Transaction  Code 

Variable  Name 

1 

-  ■ 

TC 

Definition  |  Identification  of  the  type  of  input 

- - - +  being  submitted  for  update. 


Classification  J  1  through  6 
and  Coding  j 

- > 


Uses  1  To  establish  input  criteria  by  trans- 

- ♦  action  type.  3ae  App .  A  rarough  F 


Derivation  Rule  J  Buyer  assigns  during  inpur  process. 


3  nits 

! 

H 

Format 

{  Numeric 

j  Justification  | 

Width  of 

Field 

|  1  digit 

Validity 

Rules  i  Required  i 

Range 

Content 

i 

i 

XXXXXXX  | 

1 

TBD 

1 

1 

|  Other 

Optiona 1 

i  1 

!  ! 

j 

Editing  |  Must  be  present  on  every  input  trans- 

-  -  1  action . 


APPENDIX  G  (Continued) 


Name  of  Data  Element  |  Solicitation  Number 

— - - - - f - - - 

Variable  Name  I  SLcr  NUN 

- - - - + - * - 

Definition  I  This  lumber  is  assigned  to  every  regui- 

- ♦  sition  requiring  bids  by  vendors.  ft 

is  not  the  same  as  a  contract  number.  It  is  a  unique 
number  associated  with  a  single  requisition. 

Classification  See  below, 
and  Coding  j 


- - + - 

Uses  j  Establishes  the  status  of  a  given  pro- 

- ♦  curement  as  pending  vendor  response. 


- ♦ - 

Derivation  Rule  |  Provided  by  buyer. 

- — - ♦ 


U  nits 
Por mat 

Width  of  Field 
Validity  Rules 


Editing 


1  N/A 

|  Alpha/Nu  mer: 

J  14  (13  di: 

.c|  Justification  (  N/A 

jits/alpha)  sixth  post,  alpha 

1  Required 

♦ 

xxxxxxx 

Range  |  Content  |  Other 

!  1 

TBD  j  I 

Option  a  1 

XXXXXXX  X 

1 

T3D  | 

|  Bust  oe  edited  prior  to  input  on  all 
♦  TC2  in  out. 

Optional  on  TCI  input. 


Comments 


APPENDIX  G  (Continued) 


Name  of  Data 

Element 

-4  - 
1 

Contract/Drder  Number 

Variable  Name 

—  4  — - 

1 

-4- 

CO  NT  NUM 

Definition 


|  Unique  number  associated  with  a  specific 

- ♦  procur 2  ment  and  establishing  the  award 

of  the  procurement  to  a  specific  vendor. 


——————————  — —  —  —  -f — — — —  —  -  -  — — — • 

Classif ication  |  See  below, 
and  Ceding  f 


Uses 


1  Establishes  status  of  each  procurement 

- - - ♦  request,  i.  a.,  a  specific  vendor  has 

been  awarded  the  opportunity  to  provide  the  requested 
matl.  Completes  the  final  phase  in  the  system  lifecycle. 

—  —  ——————  —  —  -f  —  —  —  ~  —  — — — —  —  —  ——  —  —  —  ————————————————————— 

Derivation  Rule  |  Provided  by  buyer. 

- + 


I 

••••  *  —  f  — —  —  —  —  —  —  —  —  — 

| Alpha/Nu meric|  Justi f ication  | 

— •  —  —  **"“+— — »— — — — — — -4—— —————— - 

Width  of  Field  |  14  (13  numeric/1  alpha)  sixth  position 

- -  „,ust  be  C,i  ,k,  Ft  or  Y 


Units 

Format 


- + • 

Js  | 
- ♦ 


Optiona  1 


Editing 


- 4- - - - 4 - - - 4 - 

|  Appears  on  every  transaction  and  must 
- 4  be  edited  for  icouracy. 


Comments 


- 4  -  - - 

I  This  is  key  sort  element  for  report 
- 4  purposes. 


Required  j 

j  Range  j 

I  Content  | 
i  1 

Orher 

xxxxxxxx  i 

1 

T3D  | 

1  1 
I 
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APPENDIX  G  (Continued) 


APPENDIX  G  (Continued) 


Name  of  Data  Element 

-f  - 

1 

Estimated  Delivery  Date 

Variable  Name 

1 

-f  • 

ESD 

Def  ir.it  ion 


|  The  vendors  estimation  of  when  material 
■+  will  os  provided. 


Classification  I  N/A 
and  Coding  I 


(Jses 


|  To  provide  query  response  to  customers. 


- * - 

Derivation  Rule  |  Provided  by  vendor  and  entered  by  buye: 
- +  on  ic3 


Units 

Format 


- ♦ 


|  Numeric  J  Justification  | 

——————————  —  —  —  — +  -  — - ■— -  —  ♦  —  — . 

Width  of  Field  |  4  digits 

- - - - - - - - f - f  — - - ♦  ■ 


Validity  Rules  I 

|  Required 

Range  |  Content 

0  h  £  T 

r 

1 

1 

! 

Option  a  1 

j  | 

xxxxxxx 

T9D  |  1 

Edi tina 


- +. 

I 


Comments 


• - ♦ - — - — - — 

|  This  is  not  a  critical  sort  element 
•- — ♦  for  report  purposes. 


APPENDIX  G  (Continued) 
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APPENDIX  G  (Continued) 


Name  of  Data  Element 

-f  - 

1 

Unpriced  Purchase  Order 

Variable  Name 

i 

-f  - 

UNPR 

Definition  |  Some  ourchase  orders  may  not  be  fixed 

- +  in  price. 


Classification  |  1 U*  Uaoricsd 

and  Coding  j  'P*“  Priced 

- + 


Uses  |  To  respond  to  external  reporting  needs. 

- - - + 


Derivation  Rule  1  Provided  by  buyer. 


- + - 

Units  | 

- ♦ - + - - 

Format  1  Alpha  |  Justification  | 

- + - - - + - f  - 

width  of  Field  l  1  character 
- - ♦— - -  +  — - - ♦ 


Validity  Rules  | 

1 

|  Required  | 
►  ‘  1 

xxxxxxxx  1 

Range  | 

1 

TBD  | 

Content 

1  Other 

1 

1 

1 

■ 

1  1 

- + - 4- - 4- - + 


Editincr  j  Must  be  edited  on  all  TC3. 

- - - +  Optional  on  all  TCU. 


APPENDIX  G  (Continued) 


Name  of  Data  Element  i  Total  Price 


Variable  Name 

|  DOL  VAL 

Definition 

1 

The  sam  total  doLlar  amount  rharaeable 

aijaiim  a 

■j  *  v  c;i  — 

Classification 
and  Coding 

1 

—  * 

N/A 

U  ses 

1 

To  repond 
report i ng 

to  internal  and  external 
needs. 

Derivation  Rul 

e  1 

Pro  vi d  ed 
buyer. 

by  vendor  and  inputea  by 

Units 

1 

Dollars 

Fermat 

1 

Numeri o 

|  Justification  | 

iiidth  of  Field 

1 

—  ♦  - 

7  digits 

Validity  Rules 


Require  d 
xxxxxxxx 


Range  |  Content 

I 

tsd  i 


Or  her 


Option  a  1 

- 

1 

| 

xxxxxxxx 

1 

1 

UHHH 

Editing 

1 

I  Required 
►  Optional 

ei iting 
on  TC'i. 

on  all  TC3  input. 

Comments 


|  Key  eLement  for  report  purposes. 


2/2 


K2S 


UNCLASSIFIED 


A  MANAGEMENT  INFORMATION  SVSTEM  FOR  THE  PURCHASING 
ACTIVITV  AT  THE  NAVAL  POSTGRADUATE  SCHOOLCU)  NAVAL 
POSTGRADUATE  SCHOOL  MONTEREV  CA  V  E  CUNNINGHAM  DEC  82 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS-1963-A 


APPENDIX  G  (Continued) 


|  Name  of  Data  Element  |  Purchase  Type 

■ - - — — - f - - - 

Variable  Name  1  PE  TYPE 

— - - - ♦  - *  -  - - 

Definition  J  Stratification  of  each  procurement  by 

- ♦  type  of  prccurenent. 

- + - --  - - - - - - 

Classification  |  Purchase  Order,  Contract,  imprest  Fund, 
and  Coding  |  BPA,  Delivery  Drier,  Modification 


(Jses 


j  To  provide  internal  management  informa- 
tion,  and  reporting  needs. 


Derivation  Rule  j  Provided  by  3uyer 
- - —  —  - —  —  +■ 


Units 


Format 


Alph 


Width  of  Field  |  1  character 


Validity  Buies  J  Required  Range  |  Content 

- +  I 

XXXXXKXX  TBD  I 


Optional  | 


Other 


Comments 


XXXXXSXX  1  TBD 


Must  oe  on  all  TC3. 
Optional  on  all  TCtt. 


|  Key  element  for  report  purposes. 


AFPENDIX  G  (Continued) 


Name  of  Data  Element  |  Purchase  Method 


Variable  Name  I  PR  1IHD 

- - - ♦ - - - , 

Definition  j  To  stratify  each  procurement  cv  in- 

- ♦  formal  bid  procedure  or  by  ferial  bid¬ 
ding/advertising. 


Classification  Negotiated,  Formal  Advertising 
and  Coding 


Uses 


I  For  internal  and  external  reporting 
purposes. 


Derivation  Rule  |  Provided  by  buyer. 


Units 


Width  of  Field 


Validity  Rules 


Alpha  |  Justification  I 


1  character 


Required  )  Ra 


XXXXCXXX 


Optional 
XXXXXXX  X 


Editing 

j 

NUSt  33 

edited 

on  all  TC3 . 

Comments 

I 

Key  eLe 

ment  for 

report  purposes. 

APPENDIX  G  (Continued) 


Name  of  Data  Element  |  Compe tition/Non-compatition 

Variable  Name  I  COMP 

■* —————————— — —  —  — — ♦  —  —————V  —  — — —  —————— 

Definition  |  The  existence  of  multiple  vendors  e 

- +  providing  bids  in  anticipation  of  w 

aing  the  award. 


Classification 
and  Coding 


Competition.  Noa-competition, 
Under  $500.00,  orders  on  F5S . 


- ♦ 

Derivation  Buie  i  Provided  by  buyer. 


CJ  nits 
Format 


|  Alpha  |  Justification  | 

—  ————————  —  —  —  —  — — — — — -  —  — —  — — — -f-< 

Width  of  Field  |  1  character 

—  — — — — - —  + - *•  - +  • 


|  Required 

♦ 

xxxxxxx 

Range 

TBD 

Content 

Other 

Optioaa  1 

xxxxxxx 

TBD 

Editing 


■  —  — — +— — — —  — — — —  • 

j  Must  appear  oa  all  TC3. 
- ♦  Optional  oa  TC4. 


Comments 


Key  element  for  report  purposes 


i  *•»» 


APPENDIX  G  (Continued) 


Name  of  Data  Element  |  Modification  of  Dollar  Amount 

- - - - - f - - - 

Variable  Name  I  MOD 

— — - - - - +  - f - 

Definition  I  This  is  an  indicator  of  a  change  in  the 

— - — —  — - ♦  dollar  amount  previously  entered  on  a 

contract/order.  It  indicates  an  increase  or  decrease,  but 
not  the  amount  of  the  change. 

Classification  I  'I'  equals  increase 

and  Codina  j  ’D*  equals  decrease 


-  - - ♦ - - - 

Uses  |  Used  to  denote  changes  in  previously 

- ♦  reported  contracts/orders. 


—  —  —  —  — +  * 
Derivation  Rule  | 
- + 


Provided  by  buyer  making  the  change. 


Units 

I 

N/A 

Format 

|  Justi f ication  | 

Width  of 

Field 

1 

1  charact- 

»  r* 

Validity 

Rules 

1 

-♦ 

Required  « 

1  Range  | 
i  i 

1  Content  | 

j  Other 

... — -- - -  — -♦ 

Editing 

•—  —  —  —  —  —  ——  ——  —  —  — «  •-  ♦ 

the  dollar  amount 
a  TC4  it  is  a 
dollar  amount 

Comments  I 

— - —  - - + 


f - ♦ - ♦  — - 

Optional  |  I  | 

XXXXXXXX  |  TBD  |  ! 

- - -  — - -  4- - + - 

This  is  an  optional  entry  on  all  input 
transactions,  however,  for  changes  m 
of  existing  contr acts/order s  utilizing 
required  entry  in  order  to  change  the 
previously  posted. 


APPENDIX  G  (Continued) 


Data  Element  |  Julian  Date  Cancelled 

- - -*■ - - — — - - 

Variable  Name  I  DATE  CANC 

—  •  -  —  —  —  —  —  —  —  —  — —  I  •  —  ••  ^  ~  —  —  —  —  —  —  —  —  —  —  —  —  ’ 

Definition  |  This  is  the  date  that  a  proorement 

- +  act i 31  is  cancelled.  The  material  is 

either  not  av^iJ.able,  is  not  authorized  for  Drocureaent, 
or  the  request  tioner  no  longer  requires  it. 

Classification  (  N/A 
and  Coaincr  | 


Oses  J  Dsed  to  denote  requisitions  which  can 

- - - ♦  net  be  completed  or,  at  the  discretion 

of  the  reguisi tioner,  are  no  longer  needed.  This  trans¬ 
action  will  have  effect  of  terminating  the  record. 


I  Derivation  Rule  |  Provided  by  buyer  assinged  to  th< 
- ♦  procurement  after  discussion  wit! 


the  reguisitio ner. 


(J  nits 

N/A 

Format 

Width  of  Field 

Numeric  |  Justification  | 

4  digits 

t  (  Other 


1  This  is  a  required  entry  on  the  TC5 
■*  transaction.  It  must  be  edited. 


Comments 


(Cont  inued) 


lPPENDIX  g 


Name  of  Data  Element 

1 

Reason  for  Cancellation 

Variable  Name 

1 

-f  - 

REASON  CANC 

Definition  |  This  orovides  managers  with  an  expian- 

- +  ation'  w  hy  the  procurement  action  was 

not  carried  out  as  previously  requested. 


Classification 
and  Coding 


Uses 

I 

l 

♦ 

I 


of  a  procurement 
such  transactions 


Derivation  Rule  | 
— - - - - ♦ 


This  element  would  be  delineated  by 
a  single  character  and  a  table  look-up. 


This  is  a  Drima  element  documenting  the 
reason  for  an  unsuccessful  fulfillment 
action.  Managers  are  keenly  aware  of 


Provided  by  buyer. 


-  - - - - - - 4- - - - - - 

Units  J  N/A 

- - - -4- - - - +  - - 4-  - 

Format  |  Alpha  I  Justification  I 

- — - + - -  - -- — - 

Width  of  Field  |  1  character 

- — ♦ - --f - + - — - -  + 


Validity  Rules  j 

Required  I 

1 

xxxxxxxx  1 

Range 

Content 

Other 

Optional  1 

1 

1 

- + - 4- - - - 4- - 

Editing  I  This  is  a  required  element  on  all  TC5 

- — - - ♦  transactions.  It  must  be  edited. 


Comments 

I - 


101 


APPENDIX  G  (Continued) 


h-h 


APPENDIX  G  (Continued) 


Name  of  Data  Element  |  Julian  Date  Referred 

—  — -  f* 

Variable  Name  I  REP  DATE 

- - - ♦ - f  - - -  — - - - — - - 

Definition  I  This  is  the  day  that  the  buyer  takes 

- +  act  io  a  to  pass  the  procurement  to 

an  outside  command  for  action. 


Classif ication  I 
and  Coding  _ j 


Uses  I  This  element  will  serve  as  a  tickler 

- - - -♦  for  tiaely  folio*- uo  action  on  the 

mart  of  buyers  assigned  to  a  given  procurement. 


Derivation  Rule  |  Provided  by  the  buyer  when  referred. 
— - - - - - + 


Dnits 

Format 


\  N/A 

- -♦  — - - 

I  Numeric 


————  —  — — -  +  ■ 

|  Justification  | 

- - - 


Width  of  Field  |  4  digits 
— - - — - 


Editing 


Required 

Range 

Content 

Other 

xxxxxxxxx 

T9D 

Optional  i 

This  entry 
It  must  be 

is  repaired  cn  all 
edited. 

TC6. 

Comments 


|  Some  linkage  with  the  PALT  determina- 
- ♦  tioa  formula  is  indicated  in  order  to 


suspend  the  PALT  calculation  while  in  the  hands  of  the 
the  referral  activity. 


APPENDIX  G  (Continued) 


f 


Name  of  Data  Element  |  Date  Referral  Response 

- — - - — - - f - - - 

Variable  Name  I  SESP  DUE 

- - - - - -  — - 

Definition  I  This  date  is  supplied  by  the 

- ♦  the  tiae  a  IC6  is  entered  to 

a  reminder  to  query  the  referral  activity  if  no 
has  been  received. 

- - - - ♦ - - - - - - - 


Due 


buyer  at 
serve  as 
response 


Classification  |  N/A 
and  Coding  _  _ j 


Uses 


j  Serves  as  a  tickler  system  for  overdue 
♦  referral  actions. 


Derivation  Rule  |  This  date  is  provided  by  -.he  buyer 

— - - ♦  upon  i n f oraation  previously  provided 

by  the  referral  activity. 


~  J:«7a; _ 

I  Numeric 
a idth  of  Field  |  4  digits 


Units 

Format 


|  Justification  | 

•  ♦ - ♦  ■ 


Validity  Rules 


j  Required 


xxxxxxx 


Optiona  1 


\  Range 

I 
I 
I 

•f  • 

I 


TBD 


Content 


Other 


J 


- - - *■ - ♦ - + - 

Editing  I  Editing  of  this  transaction  is  required 

- -  on  alL  TC6  input. 


Comments 


♦ 


I 

♦ 
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